Linking error (undefined reference to ...)

I know the title is general and is not informative enough.
I have a program which uses openimageio library.
My tools are: cmake+mingw64+windows7
I was not able to compile OpenImageIo library by myself using mingw32-make, so i decided to use already existed library (not matter what lib, static or dynamic(i tried both, error is the same), it generates error). Linking fails. To tell the truth i have not much experience in the linking.

So my linker errors look like this(if you are tired to read all this crap, i bold relevant info):

Linking CXX executable myTool.exe
CMakeFiles\myTool.dir/objects.a(OpenImageIO.cpp.obj):OpenImageIO.cpp:(.text$_ZNK11OpenImageIO4v1_08TypeDesc11elementsizeEv[_ZNK11OpenImageIO4v1_08TypeDesc11elementsizeEv]+0x22): undefined reference to `OpenImageIO::v1_0::TypeDesc::basesize() const'
CMakeFiles\myTool.dir/objects.a(OpenImageIO.cpp.obj):OpenImageIO.cpp:(.text$_ZN11OpenImageIO4v1_010ParamValueD1Ev[_ZN11OpenImageIO4v1_010ParamValueD1Ev]+0x11): undefined reference to `OpenImageIO::v1_0::ParamValue::clear_value()'
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles\myTool.dir/objects.a(OpenImageIO.cpp.obj): bad reloc address 0x11 in section `.text$_ZN11OpenImageIO4v1_010ParamValueD1Ev[_ZN11OpenImageIO4v1_010ParamValueD1Ev]'
collect2.exe: error: ld returned 1 exit status
src\myTool\CMakeFiles\myTool.dir\build.make:198: recipe for target 'src/myTool/myTool.exe' failed
mingw32-make[2]: *** [src/myTool/myTool.exe] Error 1
CMakeFiles\Makefile2:246: recipe for target 'src/myTool/CMakeFiles/myTool.dir/all' failed
mingw32-make[1]: *** [src/myTool/CMakeFiles/myTool.dir/all] Error 2
makefile:105: recipe for target 'all' failed
mingw32-make: *** [all] Error 2

I checked the OpenImageIO.lib with dumpbin.exe tool, and the required functions seems to be present
dumpbin.exe output

C:\workspace\oo-myTool_b27_oiio\oo-myTool_b27\external\openimageio3\lib>dumpbin.exe -headers OpenImageIO.lib | findstr "  basesize  "
  Symbol name  : ?basesize@TypeDesc@v1_0@OpenImageIO@@QBEIXZ (public: unsigned int __thiscall OpenImageIO::v1_0::TypeDesc::basesize(void)const )
  Name         : ?basesize@TypeDesc@v1_0@OpenImageIO@@QBEIXZ
C:\workspace\oo-myTool_b27_oiio\oo-myTool_b27\external\openimageio3\lib>dumpbin.exe -headers OpenImageIO.lib | findstr "  clear_value  "
  Symbol name  : ?clear_value@ParamValue@v1_0@OpenImageIO@@AAEXXZ (private: void __thiscall OpenImageIO::v1_0::ParamValue::clear_value(void))
  Name         : ?clear_value@ParamValue@v1_0@OpenImageIO@@AAEXXZ

Any suggestions why this happens?
I am new in a linking, could it be that objects compiled by different compilers are not compatible between each other?
Thanks in advance.
Last edited on
could it be that objects compiled by different compilers are not compatible between each other?

Yes, that is the case. When it comes to exported C++ functions, even different versions of the same compiler (e.g. VC++) can produce incompatible binaries.

OpenImage looks like it was built using some version of VC++, going by the name mangling (or decoration) -- the ?, *, @@AAEXXZ stuff


But the name the GCC linker is looking for is different (not so sure about how to decode the GCC output), so the it fails to find the required functions.

Even if the name mangling wasn't different, you could hit problem with the C runtime library. When passing std::string values (and std::vector, etc or any custom class that allocates memory) between modules, these modules must be using the same memory allocator. This means they must be linked to the same version of the C runtime library.

So you need to get hold of a build of OpenImage which has been built with your version of GCC, or build one yourself.


PS You can get away with C functions if you are careful how you export names, handle memory allocation, etc. -- but not C++.
Last edited on
Hi Andy.

Thank you very much for detailed explanation! Now i will be aware about all this. So, i will put all my efforts into compilation openimageio on my compiler.
The topic is closed.

Cheers, Alex
Last edited on
Topic archived. No new replies allowed.