List:MySQL++« Previous MessageNext Message »
From:Remi Collet Date:March 8 2007 8:42am
Subject:Re: RPM packaging and library versioning
View as plain text  
Warren Young a écrit :
> Jack Eidsness wrote:
>> 1) installing two different versions did not create a conflict; this
>> could be considered handy, if you had some reason to link to two
>> different versions of the library, but I think that's kind of far
>> fetched.
>
> This was done on purpose.  You need multiple versions of the library
> installed when you have binaries linked against one version of the
> library, then upgrade the library, then build more binaries without
> updating the old ones.  This happens frequently outside the pure open
> source world.
>
This is the purpose of -soname.

Try to give some explanations
 
Without -soname, .so is used at build time AND at runtime.

With -soname, .so is used at build time, versionned library (.so.2.0,
p.e, name given on -soname option) is used at runtime.

From "ldd examples/resetdb"
        libmysqlpp.so => /usr/lib64/libmysqlpp.so (0x00002aaaaaad5000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000035b5400000)
 
libmysqlpp doesn't use version.
libstdc++ use version.

And ll libstdc++.so*
  libstdc++.so.5 -> libstdc++.so.5.0.7  (from compat-libstdc++-33-3.2.3)
  libstdc++.so.5.0.7
  libstdc++.so.6 -> libstdc++.so.6.0.8  (from libstdc++-4.1.1)
  libstdc++.so.6.0.8
  libstdc++.so -> libstdc++.so.6.0.8  (from gcc-c++-4.1.1, which is the
devel RPM)

Using -soname, the .so (link) must be provided by mysql++-devel
sub-package as it is not required to run binaries.

Of course you could install only one libstdc++.so.5, but they
(.so.5.0.6, .so.5.0.7, ...) are supposed to be ABI compatible.

So the -soname only change when ABI change and binary compatibility is
broken.

I've look at bakefile documentation (quite poor on this feature). There
are options for "dll" (dllname, libname, version and so_version) but i
don't know how to use them...). Need more search/try.

Regards.
Remi / Fedora contributor.

Thread
Re: RPM packaging and library versioningJack Eidsness8 Mar
  • Re: RPM packaging and library versioningWarren Young8 Mar
    • Re: RPM packaging and library versioningRemi Collet8 Mar
      • Re: RPM packaging and library versioningWarren Young16 Mar
        • Re: RPM packaging and library versioningJack Eidsness16 Mar
          • Re: RPM packaging and library versioningWarren Young17 Mar
            • Re: RPM packaging and library versioningRemi Collet18 Mar
              • Re: RPM packaging and library versioningWarren Young19 Mar
                • Re: RPM packaging and library versioningJack Eidsness19 Mar
                  • Re: RPM packaging and library versioningRemi Collet19 Mar
                    • Re: RPM packaging and library versioningJack Eidsness19 Mar
                  • Re: RPM packaging and library versioningWarren Young19 Mar
                    • Re: RPM packaging and library versioningJack Eidsness19 Mar
                • Re: RPM packaging and library versioningRemi Collet19 Mar
                  • Re: RPM packaging and library versioningWarren Young19 Mar