1

I'm running MSYS2 environment for the PC - running mingw64, trying to build 64-bit binaries.

I'm trying to link to the xerces-c library (which I have downloaded and installed using pacman). Unfortunately I get unresolved link errors. It seems that the library (xerces-c) was built with size_t=unsigned long long, while what I am compiling has size_t=unsigned long - so the mangled C++ names are different - even though an unsigned long is the same as an unsigned long long in my C++ environment. Not a problem - I can patch the header files to use unsigned long long.

Unfortunately one of the objects in xerces-c overrides the new operator with their own method - the new operator implicitly calls new with size_t = unsigned long in my code. Patching the header doesn't fix this. Is there anyway around this without having to re-build xerces-c? Am I missing something?

G. Benko
  • 11
  • 1
  • 2
    What packages did you install *exactly*? This difference in size_t definition makes it seem like you're mixing 32 and 64-bit code (if xerxes has some sort of internal typedef set in a configuration header). If xerxes is typedef'ing size_t, it is in error, but I doubt that. Where exactly do you see this size_t definition you explain in your question? – rubenvb Mar 15 '17 at 07:08
  • i used pacman - which gets the package (lib and headers) and installs them from the net. **pacman -S mingw-w64-x86_64-xerces-c** is the command line I use. The size_t is in the XMemory.hpp header file - the same header file that my code is sucking in to compile my source. Only difference is my source is looking for a signature that uses unsigned long - while the library has a signature that is using unsigned long long. I found this by using a demangling tool and searching for the symbol in the library and object files. – G. Benko Mar 15 '17 at 09:28

0 Answers0