Re: libtool, c++ and SO_names
> > The problem with C++ is that it is very difficult to make any change
> > without introducing binary incompatibilities due to possible changes
> > in inline functions, virtual table layout, and data layout. Even
> > building the new package with a newer version of the compiler or std
> > library could cause problems. So, for example, 2.0.1 might be binary
> > incompatible with 2.0.0, in fact, it probably would be incompatible.
This is true.
> Depends: g++(= $MY_G++)
> into libsc-dev's depends?
You have a dependency on libstdc++2.10 or libstdc++3 depending on the
architecture. This is picked up automatically by dpkg-shlibdeps though
> > 2. On some systems, the C++ compiler must take special actions for
> > the dynamic linker to run dynamic (i.e., run-time) initializers.
> > This means that we should not call `ld' directly to link such
> > libraries, and we should use the C++ compiler instead.
>
> Is Linux a 'some system'?
Correct. You should always link with g++ to be portable.
> > 3. C++ compilers will link some Standard C++ library in by default,
> > but libtool does not know which are these libraries, so it cannot
> > even run the inter-library dependence analyzer to check how to link
> > it in. Therefore, running `ld' to link a C++ program or library is
> > deemed to fail. However, running the C++ compiler directly may lead
> > to problems related with inter-library dependencies.
>
> What does that mean?
I have no idea what he means by "inter-library dependencies". For Debian
we (speaking from working on the ia64/hppa ports) always recommend
maintainers to link with the compilers and not with the linker. So there
should not be a case where some parts are linked with ld and some parts
with g++.
> Should I refrain from shipping (shared) libraries?
No. In fact I believe policy requires this.
> What would happen if I change my c++-compiler but upstream doesn't?
> Would that mean that SO-names would be out of sync?
> Is everything easy and changing SO-names is really only needed for
> interface changes?
> If so, what does one have to consider?
There really are two parts to this question:
Interface changes (changes in any C++ methods, including type changes)
need to be reflected by a change in the soname. This should be handled
by upstream and maintained by the Debian maintainer. We should not have
different sonames than upstream. This will result in a change of the
Debian version, and either you need to change the package name (e.g.
libfoo0, libfoo1, etc) or you need to use versioned dependencies with
correct shlib files.
Compiler differences should (imo) be handled by Debian via "Depends".
All c++ shared libraries in a given distribution (potato,
woody, etc) on a given platform are compiled with the same c++ library
(whatever is specified via gcc-defaults on that platform), so there is
usually no issues as long as you Depend on the right version of
libstdc++. [1]
There are many c++ packages in Debian that build with libtool; some seem
to work :) Look for packages that Build-Depend on libtool to find these.
I would say that upstream is right to be worried about c++ and
compatibility issues, but libtool on its own is not a problem (general
issues about using libtool aside).
randolph
--
Debian Developer <tausq@debian.org>
http://www.TauSq.org/
[1] In one case that I am aware of in the past, we have shipped
libstdc++2.10 package with the same soname in potato and woody, but with
incompatible library signatures. The problem was traced down to a
changed glibc interface. To complicate matters, the soname of the c++
library itself (libapt-pkg in this case) we the same in the two
suites. To work around this the application has to Depend on
both a libstdc++ version and a libc version. In general, the upstream
application soname is likely to be different between suites, so this
is not a very frequent occurence.
Reply to: