[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libtool, c++ and SO_names



On Fri, Dec 07, 2001 at 08:56:15AM -0800, Randolph Chung wrote:
> You have a dependency on libstdc++2.10 or libstdc++3 depending on the
> architecture. This is picked up automatically by dpkg-shlibdeps though

Ah OK. That makes sense :)
 
> > >   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"
[This was quoted from the libtool-manual, not upstream, btw]

> 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++.
  
/bin/sh ../../../../bin/sc-libtool --mode=link g++ -o
../../../../lib/libSCkeyval.la ipv2.lo

So it seems libtool uses g++ for linking, right?

> > Should I refrain from shipping (shared) libraries?
> 
> No. In fact I believe policy requires this.

Sure. I would have dropped libraries completely and just used the
statically built executable, as a last resort.

> > 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. 
> 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.
 
sure.

> 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]

So, my last question to clarify: Upstream seems to be under the
impression that using another compiler would require a change in the 
SO-name.

So, there are two scenarios:

1. Upstream changes Compiler but Debian doesn't, he bumps SO and I'll
follow to stay consistent.

2. Debian changes Compiler but upstream doesn't. What to do? Is
specifying the compiler in Depends: enough?
 
> 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).
 
Thank you very much for the information!

Michael



Reply to: