results of compiling with -lmysqlclient

Lee Mx lee_ver_mx at
Thu Nov 27 09:39:30 PST 2003

>From: Matthew Seaman <m.seaman at>
>To: Lee Mx <lee_ver_mx at>
>CC: Questions at
>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, I have to
> > recompile. Is there not a way to use 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 (part of the graphics/jpeg port) is at ?
>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 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 a 
range of helpful holiday info here.

More information about the freebsd-questions mailing list