Custom OSG binaries with Visual Studio made bad things happen

Everything about development and the OpenMW source code.
Post Reply
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Custom OSG binaries with Visual Studio made bad things happen

Post by AnyOldName3 »

As part of my quest to implement shadows, I'm trying to build OpenMW against my own OSG libs and DLLs which I have the source code and debug files for instead of Ace's, which come with the CI script and do not include the PDB files.

The gist of what I've done so far is as follows:
  • Started with my day-to-day OpenMW build folder that I made with the CI script.
  • Built OSG with the same VS version as I use for OpenMW.
  • Put the headers CMake generates for OSG in a place where CMake and Visual Studio can see them (initially via symlinks, and then via hard links, as it seems that Visual Studio cannot open source files via symlinks)
  • Changed all the OSG<ComponentName>_INCLUDE_DIR, OSG<ComponentName>_LIBRARY and OSG<ComponentName>_LIBRARY_DEBUG variables in CMake GUI to point to the versions I built and did the same for the OpenThreads equivalent.
  • Configured and generated the project files.
  • Attempted to build OpenMW.
  • Got scary linker errors that should never happen.
Specifically, the errors are as follows (both as a screenshot and as a copied and pasted thing:
Spoiler: Show
Now to me, this looks like I'm somehow not including a necessary lib file for the standard library, but I would have assumed this would cause far more errors than this, and also CMake shouldn't have let that happen.

Anyone got any ideas?
crassell
Posts: 49
Joined: 26 Aug 2017, 21:10

Re: Custom OSG binaries with Visual Studio made bad things happen

Post by crassell »

Usually when I hit these sort of issues, I have to go hunting for the original symbol in a correct build and then walk the library load in the new compile. This is trivial on linux to do using ldd and readelf but you may have to use windows variants of those tools to find the right library.

A simple google for a stand in tool for ldd (ldd reads the dynamic libraries compiled into your executable):
https://stackoverflow.com/questions/199 ... on-windows

Looks nm might stand in for readelf to read the symbols:
https://www.mkssoftware.com/docs/man1/nm.1.asp

Essentially the steps should be:
1. Find the mangled name for this symbol in the working build libraries (looks like a c++ std library symbol)
void __cdecl std::basic_ofstream<char,struct std::char_traits<char> >::open(wchar_t const *,int,int)
2. Check which version of that library is being linked in with your new build.
3. If your new library doesn't contain the symbol, figure out why.

Again this is a lot easier using linux command line which is why I have ubuntu on windows installed :)
aesylwinn
Posts: 243
Joined: 14 Dec 2015, 20:30

Re: Custom OSG binaries with Visual Studio made bad things happen

Post by aesylwinn »

Lets split up that abomination!

Code: Select all

Error LNK2019 unresolved external symbol

"__declspec(dllimport) public: void __cdecl std::basic_ofstream<char,struct std::char_traits<char> >::open(wchar_t const *,int,int)" (__imp_?open@?$basic_ofstream@DU?$char_traits@D@std@@@std@@QEAAXPEB_WHH@Z) 

referenced in function "void __cdecl SceneUtil::writeScene(class osg::Node *,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" 

(?writeScene@SceneUtil@@YAXPEAVNode@osg@@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@1@Z)	openmw	C:\OpenMW-dev-2\openmw\MSVC2015_64\apps\openmw\components.lib(writescene.obj)	1	

Just a guess, but perhaps you have derived a class from osg::Node, but not provided a stream output operator overload, or whatever osg uses for serializing a node?

Edit: Reading your statement more closely, I'm guessing your current branch does build with a different version of osg. You may want to check you linking with the serialization libraries, which from a quick search appears to be osgDB. I would also suggest doing a clean build to make sure the old libraries are not being cached somewhere.
Post Reply