results of compiling with -lmysqlclient
lee_ver_mx at hotmail.com
Thu Nov 27 09:39:30 PST 2003
>From: Matthew Seaman <m.seaman at infracaninophile.co.uk>
>To: Lee Mx <lee_ver_mx at hotmail.com>
>CC: Questions at freebsd.org
>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
> > 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
> > 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, youll find a
range of helpful holiday info here.
More information about the freebsd-questions