Libraries and compiler compatibility
-
Hi, I have an application built on VS2005 which uses a static library built using VS6.0. I have noticed an issue of incorrect function getting called from a static library linked at compiled time. Note that this static library was built using Visual Studio 6.0. Whereas my application which is using the static library for linking at compile time is built using VS2005. At run time, I see that incorrect/different functions are getting called rather than the ones which are supposed to get called. To solve this issue: I rebuilt the static library (.lib) using VS2005. Then this newly built static library was used for compilation along with my application on VS2005. Then the functions are getting called correctly. I have 2 questions here: :confused: 1) This means that if there is any static library built with older version of VS6.0, then it will not work correctly with an application built with VS2005. We need to rebuild it with the same compiler as the application is built with. Is this true? why this happens in case of static libraries? 2) If above point-1 is true, then isn't it necessary to rebuild DDLs also with VS2005? If no, then why it is ok that a DLL built with older version of compiler works fine with application built with newer compiler version?
-
Hi, I have an application built on VS2005 which uses a static library built using VS6.0. I have noticed an issue of incorrect function getting called from a static library linked at compiled time. Note that this static library was built using Visual Studio 6.0. Whereas my application which is using the static library for linking at compile time is built using VS2005. At run time, I see that incorrect/different functions are getting called rather than the ones which are supposed to get called. To solve this issue: I rebuilt the static library (.lib) using VS2005. Then this newly built static library was used for compilation along with my application on VS2005. Then the functions are getting called correctly. I have 2 questions here: :confused: 1) This means that if there is any static library built with older version of VS6.0, then it will not work correctly with an application built with VS2005. We need to rebuild it with the same compiler as the application is built with. Is this true? why this happens in case of static libraries? 2) If above point-1 is true, then isn't it necessary to rebuild DDLs also with VS2005? If no, then why it is ok that a DLL built with older version of compiler works fine with application built with newer compiler version?
Many things have undergone changes from older versions of the compiler. It is not a matter of a static library or dynamic library. If you're using any of the components that have undergone a change it would become incompatible. For example, in ATL there have been many changes from ATL version 3.0 to 7.0. Many classes have been split up into many different classes. In MFC, the CString class has been changed to a template class. These are a few changes that can make older libraries incompatible with newer compilers. So when ever code for the library is available it is always better to compile them with the latest compilers. You will also be able to catch many unknown bugs this way since newer compilers do much better than older ones.
«_Superman_»
I love work. It gives me something to do between weekends. -
Hi, I have an application built on VS2005 which uses a static library built using VS6.0. I have noticed an issue of incorrect function getting called from a static library linked at compiled time. Note that this static library was built using Visual Studio 6.0. Whereas my application which is using the static library for linking at compile time is built using VS2005. At run time, I see that incorrect/different functions are getting called rather than the ones which are supposed to get called. To solve this issue: I rebuilt the static library (.lib) using VS2005. Then this newly built static library was used for compilation along with my application on VS2005. Then the functions are getting called correctly. I have 2 questions here: :confused: 1) This means that if there is any static library built with older version of VS6.0, then it will not work correctly with an application built with VS2005. We need to rebuild it with the same compiler as the application is built with. Is this true? why this happens in case of static libraries? 2) If above point-1 is true, then isn't it necessary to rebuild DDLs also with VS2005? If no, then why it is ok that a DLL built with older version of compiler works fine with application built with newer compiler version?
funwithdolphin wrote:
We need to rebuild it with the same compiler as the application is built with. Is this true? why this happens in case of static libraries?
yes. static libraries are almost never compatible between different versions of MS compilers. things like STL and MFC change between versions, interfaces break, members move around, etc..
funwithdolphin wrote:
If above point-1 is true, then isn't it necessary to rebuild DDLs also with VS2005?
that depends on what kinds of things your DLL uses in its exported interfaces.
-
Hi, I have an application built on VS2005 which uses a static library built using VS6.0. I have noticed an issue of incorrect function getting called from a static library linked at compiled time. Note that this static library was built using Visual Studio 6.0. Whereas my application which is using the static library for linking at compile time is built using VS2005. At run time, I see that incorrect/different functions are getting called rather than the ones which are supposed to get called. To solve this issue: I rebuilt the static library (.lib) using VS2005. Then this newly built static library was used for compilation along with my application on VS2005. Then the functions are getting called correctly. I have 2 questions here: :confused: 1) This means that if there is any static library built with older version of VS6.0, then it will not work correctly with an application built with VS2005. We need to rebuild it with the same compiler as the application is built with. Is this true? why this happens in case of static libraries? 2) If above point-1 is true, then isn't it necessary to rebuild DDLs also with VS2005? If no, then why it is ok that a DLL built with older version of compiler works fine with application built with newer compiler version?
As a really crass generalisation: - if your library or DLL has a C interface and your programming language can use libraries or DLLs with a C interface then you can probably get away with mixing compiler versions. This is especially true for DLLs that you load manually. - If your library or DLL are written in C++ make sure you compile your application with the same version of the compiler. Name mangling, object layout and loads of other things change from compiler version to compiler version. As well make sure you compile with as many identical compiler switches to avoid anything a bit weird sneaking in knackering your build. So this means that I can use a VC 6 C library from a VC2010 C++ application (I had to generate a new import library from the DEF file) but there's no way I could use static libraries from even VC++2008. Cheers, Ash
-
As a really crass generalisation: - if your library or DLL has a C interface and your programming language can use libraries or DLLs with a C interface then you can probably get away with mixing compiler versions. This is especially true for DLLs that you load manually. - If your library or DLL are written in C++ make sure you compile your application with the same version of the compiler. Name mangling, object layout and loads of other things change from compiler version to compiler version. As well make sure you compile with as many identical compiler switches to avoid anything a bit weird sneaking in knackering your build. So this means that I can use a VC 6 C library from a VC2010 C++ application (I had to generate a new import library from the DEF file) but there's no way I could use static libraries from even VC++2008. Cheers, Ash
Aescleal wrote:
Name mangling, object layout
For DLLs, both have remained remarkably consistent since VC++ 6.0. (Had to use VC++ 6.0, VS 2005 and VS 2008 simultaneously for a while for legacy reasons.)
-
Aescleal wrote:
Name mangling, object layout
For DLLs, both have remained remarkably consistent since VC++ 6.0. (Had to use VC++ 6.0, VS 2005 and VS 2008 simultaneously for a while for legacy reasons.)
we build our imaging libraries for VC6 VS03 VS05 VS08 VS10 debug and release for each. which would be 10 .LIBs, but... static and dynamic CRT for each. which makes 20 .LIBs, also... x64 for 05,08,10. which adds another 12 libs. so 32 static libs. plus two DLLs. for each product, each release.
-
Aescleal wrote:
Name mangling, object layout
For DLLs, both have remained remarkably consistent since VC++ 6.0. (Had to use VC++ 6.0, VS 2005 and VS 2008 simultaneously for a while for legacy reasons.)
-
I can't say I share your experience - as soon as you have DLLs that return something like an auto_ptr or even pass something as innocuous as std::string you find that the various runtime libraries you link with start interfering with each other.
With STL, yes, because it's changed without worrying about backward compatibility. I merely pointed out that name mangling and object layout has changed very little. To their credit, Microsoft made a real effort to keep name mangling the same from at least VC++ 6.0 to present day--there are some differences, but relatively few, and the object layout hasn't changed. Even the memory manager figures out how to cope with a VS 2008 application running a DLL compiled with VC++ 6.0 and running the CRT DLL. STL, on the other hand, radically changed from VC++ 6.0 to VS 2005. If you had a third party STL that was entirely under your control, however, you'd be able to get away with it with only a few exceptions (assuming you followed the rules, such as ensuring virtual tables are in the DLL and you keep the optimize flags the same.) And, when you get to static linking, all bets are off.