Libraries and compiler compatibility

[funwithdolphin]

I am working on building an application using Visual Studio 2005. Earlier I used to build it using Visual Studio 6.0.

There are some third party libraries which are linked to this application. I am not aware if these third party libraries are built using Visual Stusio 2005 or not. I guess they were built with Visual studio 6.0.

My questions are:
1] Do we need to have all third party DLLs built with same compiler version i.e. Visual Studio 2005?

2] If any libraries which are built using some other compiler version, then can these libraries be used for linking while building an application using Visual Stusio 2005?

3] Suppose there are some libraries are built using some other compiler, and are guaranteed to work on Windows 2003, then do we still need to rebuild them using Visual Studio 2005 before using them for linking against an application to be built on Visual Studio 2005?

Comments please.

[Alex F]

1, 2, 3) No.

Dll can be written in any language, and can be built with any compiler version. You can use libraries according to their public interface.

[funwithdolphin]

Thanks a lot Alex.

[funwithdolphin]

Hi Again,

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:

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?

[jnmacd]

1, 2, 3) No.

Dll can be written in any language, and can be built with any compiler version. You can use libraries according to their public interface.

Not sure if I completely agree with this.
I've had issues when I upgraded to a more recent service pack in VC6.
I compiled my EXE which is derived from a static DLL.
I got all kinds of runtime errors until I recompiled the DLL with the newest service pack.

[Lindley]

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?

The .lib file needs to be directly interpreted by the linker, so it needs to be in the format expected by the linker. Hence libs built with a different compiler version may not work.

DLLs, on the other hand, are designed to be very compartmentalized. All they need in common is to be written to the DLL interface that Windows expects; the internals can be anything at all.

Of course, there is a downside to this flexibility: you can't pass non-primitive types safely across DLL boundaries. Certainly no non-POD types, and even basic C structs could be corrupted by differing alignment settings on each side, etc. You also can't allocate memory on one side of the DLL boundary and then try to free it on the other side.

What this means is that when talking to DLLs, you need to make sure your interfaces only contain opaque pointers and/or primitives. Anything else is unreliable.

[Paul McKenzie]

Hi Again,

I have an application built on VS2005 which uses a static library built using VS6.0.

Bad idea, right from the start. All you did was build a hodge-podge of an executable that will break at any time.

You must build all of your executable with the same compiler and compiler version. Since a static library is nothing more than object code in a convenient package, then that object code must be built using the same compiler.

Imagine if you had a project that contained 6 source modules -- would you build the first 3 modules using VC 6.0, and the other three using VC 2005, and then link the object code together? What do you think you'll end up with? That is essentially what you are doing when you create a static library with one compiler and link it with code generated form another compiler. At best, you get linker errors about "unresolved external symbol" and other errors. At worst, you get an executable that is on the verge of breaking down at any time.

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?

How does your Windows OS work? It is consisted of various DLL's, and they seem to have no problems being used by any application, any compiler, and computer language.

The trick is that the DLL's use exported functions that pass and return primative types, i.e. ints, longs, double, pointers to these types, etc. If you have a DLL that instead of these parameter types, the types are C++ classes, references, etc., then that DLL is tied to that language, and you have to make sure those special, language-specific types match up exactly with what your app produces.

Regards,

Paul McKenzie

[Alex F]

Original question was about Dll. Regarding static libraries, of course, it is necessary to rebuild them.

[funwithdolphin]

Really nice information.

Many Thanks to Lindley and Paul McKenzie.