From: Matthew Seaman <[EMAIL PROTECTED]> To: Lee Mx <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: results of compiling with -lmysqlclient Date: Thu, 27 Nov 2003 12:32:47 +0000
On Thu, Nov 27, 2003 at 03:39:05AM -0800, Lee Mx wrote:
> I just realized that when I compile with -lmysqlclient I am adding the
> current version to my program or in my specific case libmysqlclient.so.10.
> When I upgrade, as I just did, to libmysqlclient.so.12, I have to
> recompile. Is there not a way to use libmysqlclient.so that is a link to
> the current active version or is there some reason why that would not be a
> good solution. I seldom see problems with backwards compatability and I
> have been know to create a link from the current library to the missing
> name without problems when I haven't had the source handy.
No. The version number on shared libraries is changed when the ABI (application binary interface) presented by the shlib changes. Your application can only load a shared library of the same ABI version as the one it was compiled against. Including the ABI version number in the shlib file name makes this explicit and helps weed out these sort of problems. The ABI can change independently of the API (application programming interface) -- so that exactly the same source code can be compiled and linked against either shlib version.
Or, at least, that's the theory: not all shlib producers get it right, confusing the shlib version with the software version -- ever wonder why libjpeg.so (part of the graphics/jpeg port) is at libjpeg.so.9 ? Some producers will only update the number when there's a change that breaks backwards compatibility but not when it breaks forwards compatibility. (The FreeBSD system libc.so works in this way: there were some important functions added to libc somewhere between 4.0 and 4.2 which means that some programs compiled under 4.3 or greater won't work on 4.0-4.2, but compile the same programs under 4.2 and they'll still continue working under later system versions.)
This problem is why you should always take any advice to solve shlib incompatability problems by making sym-links to differently named versions of the shlib with a huge grain of salt. It might work, but chances are various stuff will fail in inexplicable ways. The only real cures are either to keep multiple ABI versions of shlibs around, or to recompile everything that uses that shlib.
THanks a lot, Matthew. I assumed as much. I think I am going to start backing up some of my more frequent libs
to a compat directory. That seems to be the least bad solution.
Thanks again for such a complete explanation and examples.
From the hottest toys to tips on keeping fit this winter, you’ll find arange of helpful holiday info here. http://special.msn.com/network/happyholidays.armx
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"