Date: Thu, 27 Nov 2003 12:32:47 +0000 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 Message-ID: <20031127123247.GA17793@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <BAY8-F116XLuSbh29cM00019811@hotmail.com> References: <BAY8-F116XLuSbh29cM00019811@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--wac7ysb48OaltWcw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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=20
> current version to my program or in my specific case libmysqlclient.so.1=
0.=20
> When I upgrade, as I just did, to libmysqlclient.so.12, I have to=20
> recompile. Is there not a way to use libmysqlclient.so that is a link to=
=20
> the current active version or is there some reason why that would not be=
a=20
> good solution. I seldom see problems with backwards compatability and I=
=20
> have been know to create a link from the current library to the missing=
=20
> 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.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
--wac7ysb48OaltWcw
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQE/xe7vdtESqEQa7a0RAvBmAKCT6Q6nereQDNwJoJ5carOpSw4CngCeMIsp
yvG3hN3fWSXsb4KzzKJM86E=
=loq9
-----END PGP SIGNATURE-----
--wac7ysb48OaltWcw--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031127123247.GA17793>