Jump to content
  • Advertisement
Sign in to follow this  
floatingwoods

Big confusion: xxx.lib VS libxxx.a

This topic is 2552 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello,

I recently moved to the Qt framework. Before that I only used MSVC2005 under Windows. My application is a library (dll) that loads other dlls.The library is written in C++, but the interface is pure C.

Under MSVC2005 I obtained following files:

xxx.dll
xxx.lib

Under Qt, using the Mingw compiler, I obtain following files:

xxx.dll
libxxx.a

My question is now: can someone who uses MSVC compile an application using my library? Knowing that my library is compiled with Mingw, and the application using my library is compiled with MSVC? In a similar way, can I link an MSVC compiled library from my Mingw compiled library? This last part I can answer it by yes, because I tried it and it works without any problem. However I was told that this is not guaranteed to work (even if all interfaces are in pure C). Is that true? Because if that was true, then one could not mix libraries. One would always have to provide several versions of the same library which is very troublesome. I am aware that if the interface is not pure C (i.e. C++), then you cannot mix libraries compiled with various compilers.

Thanks for any insight

Share this post


Link to post
Share on other sites
Advertisement
Sharing static libraries across compilers can be problematic; but if all you need is to access the DLL, you can always late-bind it with LoadLibrary and GetProcAddress. That should work regardless of compiler (provided you're strictly following the C ABI).

Share this post


Link to post
Share on other sites
Thanks ApochPiQ!

This is actually a big relieve to hear. So basically:

As long as I dynamically load (i.e. late bind) shared libraries that export only C-functions, I am on the safe side, regardless whether the shared library code is C++ or the shared library was compiled with a different compiler.

Actually, as a side question: so if a shared library exports C AND C++ functions, am I still on the safe side if I late-bind only the C functions? (not using the C++ functions/objects)

Share this post


Link to post
Share on other sites

As long as I dynamically load (i.e. late bind) shared libraries that export only C-functions, I am on the safe side, regardless whether the shared library code is C++ or the shared library was compiled with a different compiler.

This is typically true. Take care to ensure that your C functions will never propagate C++ exceptions from their implementations. It's not just name mangling that doesn't mix. On MinGW, I suspect you'll want to look in to the "-mms-bitfields" option.


Actually, as a side question: so if a shared library exports C AND C++ functions, am I still on the safe side if I late-bind only the C functions? (not using the C++ functions/objects)
[/quote]
Yes, as long as you use LoadLibrary/GetProcAddress at runtime. With C-only libraries, there are techniques to generate MSVC-compatible import libraries from MinGW-compiled DLLs (meaning you don't have to manually use LoadLibrary/GetProcAddress), but I doubt that would work if your library exported C++ functions, too.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!