On Sun, Jun 30, 2002 at 07:24:44AM +0200, Matthias Klose wrote:
> Joey Hess writes:
> > ----- Forwarded message from Nathan Myers <ncm@cantrip.org> -----
> >
> > From: Nathan Myers <ncm@cantrip.org>
> > Date: Sat, 15 Jun 2002 22:35:20 +0000
> > To: joeyh@debian.org
> > Subject: C++ library packaging
> > X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20
> >
> > Hi Joey,
> >
> > I'm (re-)packaging some C++ libraries.
> >
> > Unfortunately the original packager failed to incorporate
> > dependence on the compiler/libstdc++ version in the name, so
> > that equal versions of the library, but built with different
> > compiler versions, cannot coexist.
> >
> > This is a general problem with C++ libraries (getting less so
> > as the compiler and library maintainers slouch toward a fixed
> > ABI), but is not mentioned in the policy manual. I'm guessing
> > we should incorporate the gcc-version in the package name,
> > like libxerces-gcc3.1_1.7.0-1.deb. The .so files, I suppose,
> > would have to look like lib/libxerces-gcc3.1.so.1.7.0.
>
> shouldn't this be the libstdc++ ABI version and the G++ interface
> version?
>
> > I don't know how many C++ library packages there are in Debian
> > now, but they all need this treatment.
> >
> > Of more fundamental concern, the name for libstdc++ will have
> > to change, because libstdc++ from gcc-3.1 is not upward-binary-
> > compatible with the one from 3.0.x, so (IIUC) we can't have a
> > libstdc++.so.3.1.
>
> the shared object name already is different. why change the "basename"
> as well?
Because I am afraid the package for 3.1 would still be called "libstdc++3"
if we just used the SONAME version for naming, due to questionable
use of the SONAME version - it follows the release numbers, a practice
criticised by Junichi in his libpkg guide.
The package name would have to change anyway, so we can install both 3.0
and 3.1 libraries. We can't use SONAME version, so instead of using
a kludge like libstdc++3.1 we could do the right thing.
I could be horribly wrong, of course.
> > Fortunately, they have finally committed to
> > binary compatibility for all gcc-3.1.x, but will soon release an
> > incompatible gcc-3.2. (Probably all gcc-4.x.x will be at least
> > upward-binary-compatible.)
> >
> > I've been out of the loop for some time. Has there been any
> > discussion of this?
>
> Jeff Bailey <jbailey@nisa.net> did some preparations for such an
> upgrade. Basically if Debian should change the sonames of the
> libstdc++ dependent packages or should do the transition in place.
Could he be persuaded to post his results here? Or is there a web page?
I have recently run into this problem with my packaging of SQL Relay
(ITP 119700). I have almost convinced the upstream author that setting
an SONAME is an absolute must, so if we could agree on a way to embed
compiler interface and libstdc++ ABI versions into the SONAME I would
be delighted, because then I might get it right in the packages before
inclusion into the Debian archive.
This seems to have been discussed before; so if I reinvent a lot of
mistakes in the subsequent discussion, please be gentle.
0. Current Practice
Currently Junichi's guide recommends SONAMEs like
libfoo-1.2.3.so.0
^ ^
| |
libtool -release libtool -version-info
with package names like
libfoo-1.2.3-0
The libstdc++ situation is
libstdc++.so.3 (SONAME)
libstdc++3 (package name)
1. C++ Library Naming Proposal
If g++ and libstdc++ versions always match, we might get away with a
single reference covering both: So (using libtool terminology) we'd have
to encode g++ interface and libstdc++ ABI into the -release info:
libfoo-1.2.3+3.1.so.0
^^^
|||
g++/libstdc++ version
with package names
libfoo-1.2.3+3.1-0
2. libstdc++ Naming Proposal
And for libstdc++ we'd need -release info in the first place, so we can
install several versions:
libstdc++.3.1.so.3
with package names like
libstd++-3.1-3
What a mess.
Florian
--
Ben> I don't think anybody has done a Intercal machine yet, since Intercal is
Ben> not exactly the #1 langauge to program in.
Paul> Intel has one, but few seem to want to buy it for some odd reason.
-- Ben Franchuk and Paul Repacholi in comp.sys.dec (2002)
Attachment:
pgpN5kq0uEfFM.pgp
Description: PGP signature