include and link question

[shar33oob]

Hi,

Is it a problem if I have an executable and a library use different
versions of another library.

Example:

If I have an executable: A.exe, and it basically wraps and depends on
a static library A.lib

Both A.exe and A.lib need another library B.lib

If I have a situation like this:

The A.lib library includes B.lib version 1 (uses header files from
this library)
The A.exe executable includes B.lib version 2
The A.exe executable links against B.lib version 2

Under what conditions would this be problematic?

Thanks

 

[Venu Yanamandra]

Hi,

Is it a problem if I have an executable and a library use different
versions of another library.

Example:

If I have an executable: A.exe, and it basically wraps and depends on
a static library A.lib

Both A.exe and A.lib need another library B.lib

If I have a situation like this:

The A.lib library includes B.lib version 1 (uses header files from
this library)
The A.exe executable includes B.lib version 2
The A.exe executable links against B.lib version 2

Under what conditions would this be problematic?

Thanks

The thing that must concern you is A.exe, the final binary.

Even if A.lib uses an older version of the library, if A.exe uses
B.lib of version 2, all references in A.lib would get resolved using
B.lib of version2.

The problem would arise if there is no backwards compatibility
provided by B.lib. But, ideally that would never happen.
So, I think you are safe. Link A.exe using A.lib and {B.lib of
version2}, and run a sanity check. This sanity check must have A.lib
calling B.lib's old functions and also, A.exe making use of B.lib's
new functions.

 

[Jorgen Grahn]

Hi,

Is it a problem if I have an executable and a library use different
versions of another library.

Example:

If I have an executable: A.exe, and it basically wraps and depends on
a static library A.lib

Both A.exe and A.lib need another library B.lib

If I have a situation like this:

The A.lib library includes B.lib version 1 (uses header files from
this library)
The A.exe executable includes B.lib version 2
The A.exe executable links against B.lib version 2

Under what conditions would this be problematic?

I'd say "all the time". Stop doing that.

You only link with B.lib once, so part of your code has a mismatch: it
includes headers which don't match what you later link against.
You'll get nasty bugs if for example a struct got rearranged.

/Jorgen

 

[BGB / cr88192]

I'd say "all the time". Stop doing that.

You only link with B.lib once, so part of your code has a mismatch: it
includes headers which don't match what you later link against.
You'll get nasty bugs if for example a struct got rearranged.

yep.

I know of code which uses internal version numbers and things like
build-dates, ... to try to protected against mismatched linkage (usually WRT
DLL's...). wrong date or version numbers means one side or the other will
refuse to work (typically showing a "Fatal Error" message box and dying or
similar).

handling versioning issues cleanly usually requires a little work both on
the part of the library and app developer, where the library developer needs
to try to avoid creating backwards-compatibility (or forwards-compatibility)
problems (usually requires being a bit "pedantic" WRT the design and
extension of API's, which are rarely done the same as how one would handle
most "internal" code).


it is common to regard the external API as a sort of "contract", where
changes and additions are made with caution, and usually the externally
presented interface is separate from whatever is taking place internally
(one does not normally expose internal functions or data structures, as
these are regarded as "off limits" to the client code).

and, many C++ libs will present a plain C interface to the outside world,
place restrictions on the use of memory and structures, ... as well. (in
fact, it may often be the case that the C++ interface for a C++ based
library is actually a wrapper over its C API).


client code may also have to deal with the case of trying to avoid issues
with older or newer versions of a library (such as the issue that an older
version may not export certain functions or support certain features, and
that a newer version may change aspects of its API), or possibly, one will
end up linking with a version of the library produced by a different author
or vendor than the one originally expected.

so, it is all a bit fussy, and has to all be handled with care otherwise
things will tend to blow up in ones' face, or at least create a whole lot of
bugs...