results of compiling with -lmysqlclient
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. Thanks for clearing this up for me. lee _ Set yourself up for fun at home! Get tips on home entertainment equipment, video game reviews, and more here. http://special.msn.com/home/homeent.armx ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: results of compiling with -lmysqlclient
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. Cheers, Matthew -- 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 pgp0.pgp Description: PGP signature
Re: results of compiling with -lmysqlclient
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 + 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, youll find a range 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]
Re: results of compiling with -lmysqlclient
On Thu, Nov 27, 2003 at 09:39:28AM -0800, Lee Mx wrote: 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. Note that portupgrade(1) and pkg_deinstall(1) do this automatically whenever you update a package containing share objects or libraries -- check out /usr/local/lib/compat/pkg and the output of 'ldconfig -r' for details. There's also the sysutils/libchk port which will help you find binaries that link against those old library versions. Cheers, Matthew -- 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 pgp0.pgp Description: PGP signature
Re: results of compiling with -lmysqlclient
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 18:27:23 + On Thu, Nov 27, 2003 at 09:39:28AM -0800, Lee Mx wrote: 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. Note that portupgrade(1) and pkg_deinstall(1) do this automatically whenever you update a package containing share objects or libraries -- check out /usr/local/lib/compat/pkg and the output of 'ldconfig -r' for details. There's also the sysutils/libchk port which will help you find binaries that link against those old library versions. Thanks, Matthew. In this case the box and installation are new and the programs are old. I'm going to check out libchk. In fact, I'm installing it as I write. It sounds like something very useful that is missing in my took kit. Thanks again, les _ Has one of the new viruses infected your computer? Find out with a FREE online computer virus scan from McAfee. Take the FreeScan now! http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
