I am trying to add FreeImage to LSEngine and have encountered linker errors.
I have posted the details here:
http://sourceforge.net/p/freeimage/discussion/36110/thread/fcf4b8a9/?limit=25#ff6a/a668

What you can take away from it:

• The FreeImage static library is built with no errors and copied to a certain location as a post-build event.
• I am correctly linking to that library, in 2 ways (and this is verified).
  • As an additional dependency.
  • As a project reference.
• FreeImage_Initialise and FreeImage_DeInitialise are part of the library. They are declared in FreeImage.h, defined in Plugin.cpp, and both files are part of the FreeImage static library project.
• As per the second post there, I have copied the pre-defined macros from the FreeImage project to LSImageLib so that both projects see the headers exactly the same way. This changed the error from __imp__FreeImage_Initialise@4 to _FreeImage_Initialise@4.
• _FreeImage_Initialise is inside FreeImage.lib, _FreeImage_Initialise@4 is not.

Based on #4 and #5, it is simply a matter of decorations, but it was past my bedtime and I ran out of ideas to try.
Of note: In FreeImage.h, the functions are inside and extern "C" {} block but the definitions inside Plugin.cpp are compiled as C++.
What I have tried from there:

• Made a file called Plugin.c and moved those function definitions into it (and added it to the project).
  • It never compiled the file for some reason. I would click the file and tell it compile Plugin.c, but it would say, “Compiling Plugin.cpp…”.
  • The functions use new and delete, so they couldn’t compile to C anyway, even if Visual Studio did recognize it.

• I moved the declarations out of the extern "C" {} block.
  • I got the same linker error but with a different mangling of the name.
• I set FreeImage’s project settings to fully match those of LSImageLib’s, particularly including the default calling convention (which was set to __cdecl but LSImageLib has it set to __stdcall).
  • No change to the error.

I was simply too tired to continue and I couldn’t think of any more ideas to try.
It is clearly a name-mangling/decoration issue with a very tricky solution.
Any ideas appreciated.


L. Spiro

I can’t test but I believe I was so close but just barely missed it.
Linker Tools Error LNK2001

Interpreting the Output
When a symbol is unresolved, you can get information about the function by the following guidelines:
On x86 platforms, the calling convention decoration for names compiled in C, or for extern "C" names in C++, is:


__cdecl

Function has an underscore (_) prefix.


__stdcall

Function has an underscore (_) prefix and an @ suffix followed by the dword aligned size of parameters on the stack.


__fastcall

Function has an @ prefix and an @ suffix followed by the dword aligned size of parameters on the stack.

FreeImage.lib is compiling as __cdecl (even though as I mentioned I forced it in a few ways to compile as __stdcall) and LSImageLib defaults to using __stdcall.


This basically resolves the cause of the error, but since I have already told FreeImage to compile everything as __stdcall and I still get the same error I need to try a more brute-force approach to getting the calling conventions to match.


I don’t have the project with me now but I know for-sure that the reason is __cdecl inside FreeImage and __stdcall in my project, so I will definitely be able to solve it when I get back to it.


L. Spiro

It’s not a surprise that if I had to resort to posting about a linker error that there was something suspicious happening in the first place.
https://sourceforge.net/p/freeimage/discussion/36110/thread/fcf4b8a9/#3159

It is literally impossible to build a static library of FreeImage. Its level of error is over 9,000.

Thank you for reading.


L. Spiro