List:General Discussion« Previous MessageNext Message »
From:Dan Nelson Date:May 25 2009 6:34am
Subject:Re: Linking for maximum portability
View as plain text  
In the last episode (May 23), Matthew Kettlewell said:
> I'm trying to build an executable that would be distributed in binary
> form, but needs to link to a MySQL DB -
> 
> problem  I'm finding is that the shared libs range in name 
> libmysqlclient.so.15 , libmysqlclient.so.14, etc...  And throw a 
> run-time error when it isn't found...
> 
> Is there a way to compile to just the .so, without the extension that 
> would be more portable?

No, the libraries have different numbers because the ABI has changed, due to
functions being removed or structure elements changing.  You can't reliably
compile against one version and expect any other version to work.

> Or is there a better approach to this?  or do I just need to maintain a 
> copy that is linked to each different version ?

If the platform you are compiling for has bundled a version of mysql, link
against that to ensure that your application will run on any system. 
Solaris 10, for example, includes a libmysqlclient.so.12 (corresponding to
mysql 4.0) in its SUNWmysqlu package, so you know that all Solaris 10
systems have it or can easily install it.

Otherwise, link against the latest stable version there is an OS-supplied
package for.  Most packaging systems for Linux and *BSD will separate
libraries into non-conflicting packages, so an end-user can have multiple
library versions installed at once.

Another option is to statically link your application so that there are no
shared-library dependencies at all.

-- 
	Dan Nelson
	dnelson@stripped
Thread
Linking for maximum portabilityMatthew Kettlewell24 May
  • Re: Linking for maximum portabilityDan Nelson25 May