Project Glider for O2016

I'm having issues with XRSound. I'm initialising it in clbkPostCreation like so:
Code:
void Glider::clbkPostCreation()
{
	XRSound *CreateInstance(VESSEL *pVessel);

}

But when I ask it to play a sound, like this:
Code:
XRSound::PlayWav(10037, true, 1.0);
I get "a nonstatic member reference must be relative to a specific object".
How do I fix this?

You should learn more about pointers and classes in C++.

You need a private field in your class that holds the XRSound instance pointer. Let's say it is called "sound". You'd declare it in your class header:
Code:
#include "XRSound.h"
class Glider: public VESSEL4 {
...
private:
     XRSound *sound;
}

Then you assign the new instance pointer to this field like so:
Code:
void Glider::clbkPostCreation()
{
	sound = XRSound::CreateInstance(this);
}

To play sound, you have to dereference the pointer in the sound field like so:
Code:
sound->PlayWav(10037, true, 1.0);

In the destructor, you do this to clean up memory:
Code:
delete sound;
 
Alright, that works. But now I get this:
Code:
1>------ Build started: Project: Glider, Configuration: Release Win32 ------
1>LINK : fatal error C1047: The object or library file '..\..\..\..\Desktop\Orbiter\Orbitersdk\XRSound\XRSound.lib' was created with an older compiler than other objects; rebuild old objects and libraries
1>LINK : fatal error LNK1257: code generation failed
1>Done building project "Glider.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
 
Code:
1>LINK : fatal error C1047: The object or library file '..\..\..\..\Desktop\Orbiter\Orbitersdk\XRSound\XRSound.lib' was created with an older compiler than other objects; rebuild old objects and libraries

Rebuilding of the library is only possible with the source code at hand. I think you have to talk to dbeachy1 for this. With my VS 2015, the lib is linking fine. What VS version do you use?
 
Alright, that works. But now I get this:
Code:
1>------ Build started: Project: Glider, Configuration: Release Win32 ------
1>LINK : fatal error C1047: The object or library file '..\..\..\..\Desktop\Orbiter\Orbitersdk\XRSound\XRSound.lib' was created with an older compiler than other objects; rebuild old objects and libraries
1>LINK : fatal error LNK1257: code generation failed
1>Done building project "Glider.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

From Googling for C1047, it looks like this is happening because your VS 2017 project has Link Time Code Generation enabled in your project settings, which an optional feature of Visual Studio to (apparently?) speed up compilation times. XRSound is built with Visual Studio 2015.

If you disable Link Time Code Generation in your project settings (Project properties -> Linker -> Optimization ->Link Time Code Generation -> Set to "default" to disable it), then it will hopefully build successfully.
 
From Googling for C1047, it looks like this is happening because your VS 2017 project has Link Time Code Generation enabled in your project settings, which an optional feature of Visual Studio to (apparently?) speed up compilation times. XRSound is built with Visual Studio 2015.

If you disable Link Time Code Generation in your project settings (Project properties -> Linker -> Optimization ->Link Time Code Generation -> Set to "default" to disable it), then it will hopefully build successfully.

Just tried it, no luck...
Code:
1>------ Build started: Project: Glider, Configuration: Release Win32 ------
1>Glider.obj : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
1>LINK : fatal error C1047: The object or library file '..\..\..\..\Desktop\Orbiter\Orbitersdk\XRSound\XRSound.lib' was created with an older compiler than other objects; rebuild old objects and libraries
1>LINK : fatal error LNK1257: code generation failed
1>Done building project "Glider.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
 
Strange. Are you using C++ with managed code extension?
 
Can you post the command line of the compiler from your project settings to compare?

Code:
/OUT:"C:\Users\toffe\source\repos\Glider\Release\Glider.dll" /MANIFEST /NXCOMPAT /PDB:"C:\Users\toffe\source\repos\Glider\Release\Glider.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /IMPLIB:"C:\Users\toffe\source\repos\Glider\Release\Glider.lib" /DEBUG /DLL /MACHINE:X86 /OPT:REF /SAFESEH /INCREMENTAL:NO /PGD:"C:\Users\toffe\source\repos\Glider\Release\Glider.pgd" /SUBSYSTEM:WINDOWS /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"Release\Glider.dll.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /TLBID:1
 
/PGD makes no sense. Its DEBUG and Profiler optimization is not useful anyway right now.

Why are you using /OPT:REF and /OPT:ICF, if you are compiling in /DEBUG settings? Usually, you should not be optimizing at all with /DEBUG active, because it makes the additional debug information useless.

/SAFESEH is one possible issue there, why is it set? Default is not using it.

/TLBID:1 is also not making sense, since 1 is the default value. Is it explicitly set?

Its all new stuff for VS 2015 and not all is activated by default according to M$.
 
/PGD makes no sense. Its DEBUG and Profiler optimization is not useful anyway right now.

Why are you using /OPT:REF and /OPT:ICF, if you are compiling in /DEBUG settings? Usually, you should not be optimizing at all with /DEBUG active, because it makes the additional debug information useless.

/SAFESEH is one possible issue there, why is it set? Default is not using it.

/TLBID:1 is also not making sense, since 1 is the default value. Is it explicitly set?

Its all new stuff for VS 2015 and not all is activated by default according to M$.

Alright, looked for those settings and (hopefully) fixed them. Still fails to build.

Code:
/OUT:"C:\Users\toffe\source\repos\Glider\Release\Glider.dll" /MANIFEST /NXCOMPAT /PDB:"C:\Users\toffe\source\repos\Glider\Release\Glider.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /IMPLIB:"C:\Users\toffe\source\repos\Glider\Release\Glider.lib" /DEBUG:FULL /DLL /MACHINE:X86 /OPT:REF /SAFESEH:NO /INCREMENTAL:NO /PGD:"C:\Users\toffe\source\repos\Glider\Release\Glider.pgd" /SUBSYSTEM:WINDOWS /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"Release\Glider.dll.intermediate.manifest" /OPT:NOICF /ERRORREPORT:PROMPT /NOLOGO /TLBID:1
 
Alright, looked for those settings and (hopefully) fixed them. Still fails to build.

Still looks strange to me. I have not looked at the 2017 command line yet, the last I manually checked was 2013, but I do know that my old Gemini modules compile well with XRSound.

Some settings are as I expect them, but some others make no sense at all, the changes are not default behavior now, but specifically the opposite. And you still have link time optimizations active.
 
Just tried it, no luck...
Code:
1>------ Build started: Project: Glider, Configuration: Release Win32 ------
1>Glider.obj : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
1>LINK : fatal error C1047: The object or library file '..\..\..\..\Desktop\Orbiter\Orbitersdk\XRSound\XRSound.lib' was created with an older compiler than other objects; rebuild old objects and libraries
1>LINK : fatal error LNK1257: code generation failed
1>Done building project "Glider.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

According to your build output log, something in your project appears to be compiling managed (i.e., .NET) code:

Code:
1>Glider.obj : [COLOR="Red"]MSIL .netmodule or module compiled with /GL found[/COLOR]; restarting link with /LTCG;

...and so the compiler then automatically enables the /LTCG flag, which is the flag we need to disable:

Code:
1>Glider.obj : MSIL .netmodule or module compiled with /GL found; [COLOR="red"]restarting link with /LTCG;[/COLOR] add /LTCG to the link command line to improve linker performance

...and since the compiler is automatically re-enabling the /LTCG flag, the error still occurs. We need to figure out how to disable that flag and keep the compiler from auto-enabling it.

MSIL is only present with managed code (i.e., .NET). The /GL flag is for "Whole Program Optimization". The first thing I would do is check your project settings and make sure you aren't building a .NET project or including any managed code in your project -- you should not be compiling any managed code for an Orbiter add-on.

Can you successfully build it in debug mode (as opposed to release mode)? Your debug project configuration should certainly not specify Whole Program Optimization -- optimization should be disabled for debug builds. This setting configured in Project Properties -> C/C++ -> Optimization -> Whole Program Optimization -> set to No for debug builds, Yes for release builds.

But the root issue appears to be that your project is trying to build some managed code -- do you have any .cs files in your project?
 
According to your build output log, something in your project appears to be compiling managed (i.e., .NET) code:

Code:
1>Glider.obj : [COLOR="Red"]MSIL .netmodule or module compiled with /GL found[/COLOR]; restarting link with /LTCG;

...and so the compiler then automatically enables the /LTCG flag, which is the flag we need to disable:

Code:
1>Glider.obj : MSIL .netmodule or module compiled with /GL found; [COLOR="red"]restarting link with /LTCG;[/COLOR] add /LTCG to the link command line to improve linker performance

...and since the compiler is automatically re-enabling the /LTCG flag, the error still occurs. We need to figure out how to disable that flag and keep the compiler from auto-enabling it.

MSIL is only present with managed code (i.e., .NET). The /GL flag is for "Whole Program Optimization". The first thing I would do is check your project settings and make sure you aren't building a .NET project or including any managed code in your project -- you should not be compiling any managed code for an Orbiter add-on.

Can you successfully build it in debug mode (as opposed to release mode)? Your debug project configuration should certainly not specify Whole Program Optimization -- optimization should be disabled for debug builds. This setting configured in Project Properties -> C/C++ -> Optimization -> Whole Program Optimization -> set to No for debug builds, Yes for release builds.

But the root issue appears to be that your project is trying to build some managed code -- do you have any .cs files in your project?

No and no. Debug fails as well and I don’t think I have .cs files.

---------- Post added at 09:04 AM ---------- Previous post was at 05:32 AM ----------

Tried everything I could think of to get it to work, to no avail.
Argh, so frustrating... I want control over my destiny/code M$. Lemme have it, darn it!

---------- Post added at 10:12 AM ---------- Previous post was at 09:04 AM ----------

What could I do from here? I really like XRSound... is there something like VS2015 compatiblity mode?
 
I'll look into this more tonight -- maybe the problem is that XRSound.lib is compiled with "/GL"? I'll report back when I know more.

EDIT:
From taking a quick look at this, I am able to get the same message if I set "Link Time Code Generation" to No but still have "Whole Program Optimization (/GL)" set to Yes. As a test, can you please try this:

1. In your project settings, set C/C++ -> Optimization -> Whole Program Optimization = No for both debug and release builds (it should already be set to No for debug builds).
2. Do a 'rebuild all' of your project.

If the compiler still forces /LTCG on at that point, then it sounds like the compiler is seeing that the code in XRSound.lib was compiled with /GL (Whole Program Optimization) = Yes, and so that then forces Visual Studio to set /LTCG = On with any project that links with XRSound.lib (argh!). What I can do in that case is post a link here to the new XRSound 2.0 Beta-3, which I'll update to compile with Whole Program Optimization = Off, which should hopefully fix the issue. There is not much actual code in XRSound.lib anyway, so the performance impact from that should be negligible: it simply calls XRSound.dll, if present.
 
@zachary77 -- as a first test, can you please download the new XRSound 2.0 Beta-3 and see if you can link with its XRSound.lib using your current settings? As well as including support for module sounds (i.e., Orbiter modules can use XRSound without binding it to an Orbiter vessel), XRSound.lib was built with Link Time Code Generation and Whole Program Optimization set to No. I'm curious to see if that works around the issue.

Temporary download link is:
XRSound 2.0 Beta-3

As a side note, since the object structure of the XRSound interface object in XRSound.lib changed significantly from version 1.0, it was necessary to rebuild the XR vessels using the new XRSound 2.0 library. (Hopefully the XRSound interface won't need to change significantly again in the future.) EDIT: I figured out why the XRSound 2.0 beta-3 was not backwards-compatible with XRSound 1.1 and fixed it. This means that the upcoming XRSound 2.0 version will work with any existing vessels that link with XRSound 1.x as well -- no need to relink. :tiphat: The current plan is to hold off on releasing XRSound 2.0 and the updated XR vessels until Orbiter MMU (oMMU) is ready, but I could release XRSound 2.0 early if it's necessary to fix this issue with linking with different compiler versions.
 
Last edited:
@zachary77 -- as a first test, can you please download the new XRSound 2.0 Beta-3 and see if you can link with its XRSound.lib using your current settings? As well as including support for module sounds (i.e., Orbiter modules can use XRSound without binding it to an Orbiter vessel), XRSound.lib was built with Link Time Code Generation and Whole Program Optimization set to No. I'm curious to see if that works around the issue.

Temporary download link is:
XRSound 2.0 Beta-3

As a side note, since the object structure of the XRSound interface object in XRSound.lib changed significantly from version 1.0, it was necessary to rebuild the XR vessels using the new XRSound 2.0 library. (Hopefully the XRSound interface won't need to change significantly in the future.) The current plan is to hold off on releasing XRSound 2.0 and the updated XR vessels until Orbiter MMU (oMMU) is ready, but I could release XRSound 2.0 early if it's necessary to fix this issue with linking with different compiler versions.

Err... it doesn’t work. Now it’s saying something about a mismatch between static debug and dynamic debug
 
Err... it doesn’t work. Now it’s saying something about a mismatch between static debug and dynamic debug

I guess the best course of action now is to show the code someone you trust and who is willing to review your project. This remote-guessing leads to nowhere IMHO.
 
Woo482 has Visual Studio 2017 installed, and while we were chatting on IRC, he was kind enough to do some detailed testing for me linking his Orbiter MMU (oMMU) DLL with XRSound 1.1 and then XRSound 2.0 Beta-3. Here are the results:

  • Both XRSound 1.1 and 2.0 Beta-3 link successfully in Debug mode (because C/C++ -> Optimization -> Whole Program Optimization defaults to No for debug builds).
  • Linking with XRSound 1.1 in Release mode with Whole Program Optimization set to Yes (its default for release builds) results in the "XRSound.lib' was created with an older compiler than other objects" link error, which is what I also reproduced locally yesterday and is the same error that @zachary77 is seeing.
  • Linking with XRSound 1.1 in Release mode with Whole Program Optimization set to No builds successfully. This fits with what I found via Google about /GL being incompatible between different Visual C++ compiler versions, so it makes sense.
  • Linking with the new XRSound 2.0 Beta-3 in Release mode works fine even if Whole Program Optimization is set to Yes, because that version of XRSound.lib was compiled with Link Time Code Generation and Whole Program Optimization set to No.

So, to summarize:
  • Debug builds linked fine as-is with both XRSound 1.1 and XRSound 2.0 Beta-3.
  • Release builds linked fine with XRSound 1.1 if C/C++ -> Optimization -> Whole Program Optimization = No (i.e., this disables /GL).
  • Release builds linked fine with XRSound 2.0 Beta-3 regardless of the C/C++ -> Optimization -> Whole Program Optimization setting.

Here is the compiler output from Woo482's Visual Studio 2017 Orbiter MMU project linking successfully in Release mode with XRSound 1.1 with C/C++ -> Optimization -> Whole Program Optimization = No:

Code:
Release mode command line:
/GS- /analyze- /W3 /Gy /Zc:wchar_t /I"D:\Orbiter\Orbiter 2016\Orbitersdk\include" /Zi /Gm- /O2 /sdl /Fd"C:\Users\adam_\source\repos\oMMU\oMMU MMU\Release\vc141.pdb" /Zc:inline /fp:fast /D "_CRT_SECURE_NO_WARNINGS" /D "_WINDLL" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /Gd /Oy- /Oi /MT /Fa"C:\Users\adam_\source\repos\oMMU\oMMU MMU\Release\" /EHsc /nologo /Fo"C:\Users\adam_\source\repos\oMMU\oMMU MMU\Release\" /Fp"C:\Users\adam_\source\repos\oMMU\oMMU MMU\Release\oMMU_MMU.pch" /diagnostics:classic
 
Release mode console output:
1>------ Build started: Project: oMMU_MMU, Configuration: Release Win32 ------
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppBuild.targets(373,5): warning MSB8004: Output Directory does not end with a trailing slash.  This build instance will add the slash as it is required to allow proper evaluation of the Output Directory.
1>cl : Command line warning D9025: overriding '/sdl' with '/GS-'
1>oMMU_MMU.cpp
1>   Creating library D:\Orbiter\Orbiter 2016\Modules\oMMU_MMU.lib and object D:\Orbiter\Orbiter 2016\Modules\oMMU_MMU.exp
1>Generating code
1>All 130 functions were compiled because no usable IPDB/IOBJ from previous compilation was found.
1>Finished generating code
1>XRSound.lib(XRSound.obj) : warning LNK4099: PDB 'XRSoundLib.pdb' was not found with 'XRSound.lib(XRSound.obj)' or at 'D:\Orbiter\Orbiter 2016\Modules\XRSoundLib.pdb'; linking object as if no debug info
1>XRSound.lib(XRSoundImpl.obj) : warning LNK4099: PDB 'XRSoundLib.pdb' was not found with 'XRSound.lib(XRSoundImpl.obj)' or at 'D:\Orbiter\Orbiter 2016\Modules\XRSoundLib.pdb'; linking object as if no debug info
1>oMMU MMU.vcxproj -> D:\Orbiter\Orbiter 2016\Modules\oMMU_MMU.dll
1>Done building project "oMMU MMU.vcxproj".

Thanks again to Woo482 for testing this for me. :tiphat:

@zachary77 -- since you're getting different results from what Woo482 is seeing with his Visual Studio 2017 project, it sounds like some other issue besides an XRSound.lib issue. Face's suggestion sounds like the way to proceed here, if you can.
 
I agree with that. I was gonna release the source code in the next release anyway. When I get home I’ll do it. Thanks for all your help
 
Back
Top