- Oct 26, 2011
- Reaction score
[COLOR="Red"]orbitersdk.lib(Orbitersdk.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in AABBUtil.obj [c:\Program Files (x86)\Orbiter\D3D9Client\Orbitersdk\D3D9C lient\D3D9Client.vs2015.vcxproj] ..\..\Modules\Plugin\D3D9Client.dll : fatal error LNK1319: 1 mismatches detected [c:\Program Files (x86)\Orbiter\D3D9Client\Orbitersdk\D3D9Client\D3D9Client.vs2015.vcxproj][/COLOR]
This post here has one answer from 2010 agreeing that MT and MD are mutually exclusive, but there are two more recent answers with zero votes that suggest workarounds.Oh, no. I am in the process of switching my compiler toolchain to VS2015. I guess it was naive to think that this could work seamlessly.
Is it possible that newer versions of VS don't allow linking together modules that have been compiled with a mix of /MT and /MD compiler options? That would be pretty catastrophic for Orbiter, because it would require all addons to be compiled with the same options (and maybe even with the same VS version?) This page seems to suggest so.
I tried to switch the option for the orbitersdk.lib from /MD to /MT, but then I get the same error as you do in reverse for all plugins compiled with the /MD option.
As a last resort I have now compiled orbitersdk.lib with the VS2008 runtimes. This appears to fix the /MT /MD incompatibility for me, but it seems like a hack at best.
I have pushed a new commit with the recompiled orbitersdk.lib. Can you check if this works for you?
Can you think of a better way to resolve this problem?
Never underestimate the possible impact of "small changes" :lol:Oh, no. I am in the process of switching my compiler toolchain to VS2015. I guess it was naive to think that this could work seamlessly.
Sorry, no. I was also very puzzled as this came up. Even as I used the same toolchain!Can you think of a better way to resolve this problem?
For the record, I tried this and it didn't make a difference for me.I'm not sure how the "/MT /Zl" approach is supposed to work, but I suppose it could be worth a try.
I've done a quick test against OMP (which still is a 2008 solution). It had no problems to link against the new lib.It might be a good idea for other developers to try the latest SVN commit, so I can get an idea if things are majorly broken as a result of the compiler switch.
I was just in the shower thinking that... :lol:It might be a good idea for other developers to try the latest SVN commit, so I can get an idea if things are majorly broken as a result of the compiler switch.
Yep, that was it! Both solutions work.Thanks for the detailed analysis!
Regarding the Titan issue: I recently created new textures for Titan in Orbiter2016 format (can be downloaded here) and I realised that I may have inadvertently put the config file for this new texture set into the commit.
Can you try one of the following:
If the first of these works, I'll revert the Titan.cfg to the old version for the next commit.
- replace Config/Titan.cfg with SVN.r73 or earlier (or just remove the lines "TileFormat = 2; CloudFormat = 2; LabelFormat = 2), or
- Download the .tree files for the new textures and put them into Textures/Titan
For SSU that seems to be the case, but I don't about everybody else. And AFAIK, only the libraries would need to match.Regarding the Debug/Release conflict: Do I understand correctly that you can no longer do a debug build of your own module if the host Orbiter application is a release build? This seems bizarre. Anyway, I don't see a reason not to provide the debug builds, although I still don't really understand why the new VS version is now so picky about matching build options. Would this only require the debug binaries, or any additional files?
This link has some info about the .pdb files. At least for the release version, I'd add a 3rd option: no debug info. IMO even for the debug version the debug info is not needed for us devs, as we are not debugging the code in the lib. :shrug: But this might be a PITA for you having to turn that off and on before making the lib public.The warnings talk about pdb files. Is this where the debug info lives these days? Is the debug information no longer part of the binary? If these additional files are required, it might changing my build system a bit, because at the moment pdb files aren't part of the deployment set.