Date: Thu, 27 Nov 2003 09:39:28 -0800 From: "Lee Mx" <lee_ver_mx@hotmail.com> To: m.seaman@infracaninophile.co.uk Cc: Questions@freebsd.org Subject: Re: results of compiling with -lmysqlclient Message-ID: <BAY8-F92wc87rY51zMv0001db2e@hotmail.com>
next in thread | raw e-mail | index | archive | help
>From: Matthew Seaman <m.seaman@infracaninophile.co.uk> >To: Lee Mx <lee_ver_mx@hotmail.com> >CC: Questions@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 >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. ed _________________________________________________________________ >From the hottest toys to tips on keeping fit this winter, you’ll find a range of helpful holiday info here. http://special.msn.com/network/happyholidays.armx
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BAY8-F92wc87rY51zMv0001db2e>