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

Re: Improving dependencies on shared libraries



On Sun, May 27, 2007 at 09:56:13AM +0200, Raphael Hertzog wrote:
> On Sun, 27 May 2007, Mike Hommey wrote:
> > > Some research Scott James Remnant did back in the woody days indicated that
> > > with a more finely-grained shlibs implementation, the majority of packages
> > > could run fine against glibc 2.0.
> > > 
> > > No such luck with lenny due to the change of symbol hash tables which
> > > now require a recent ld.so to parse, but it'll probably take more than a
> > > full release cycle to get this implemented and widely adopted anyway, so...
> > 
> > When is it supposed to happen or have happened ? Because I just tried
> > installing libxml2 and libxml2-utils from sid on an etch system, with
> > dpkg --force-depends, and xmllint works perfectly fine...
> 
> The change hash-style=gnu happened with gcc-4.1 4.1.2-5 although the
> version -7 changes this again to hash-style=both. In the mean time, libc6
> 2.5-5 bumped its shlibs to avoid problems with packages compiled with a
> gcc using hash-style=gnu.
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421790
> 
> So maybe the problem affects only some architectures which do not support
> hash-style=both? What arches do not support this?
> 
> For me it would seem wise to keep hash-style=both for the entire lenny
> cycle and drop it during the lenny+1 cycle to have a smooth transition on
> this aspect.

  No the problem is worse than that, ld.so has supported both styles for
hashing for years, so it's not really a matter at *run*-time. Though,
the rest of the toolchain (binutils in particular) did not, and isn't
able to grok hash-style=gnu in etch. Hence e.g. if libxml2 has been
build with -hash-style=gnu you won't be able to link any program against
it.

  The glibc shlibs is a very loosy and convoluted way to make sure that
the toolchain is recent enough, because the change was uncoordinated.
Though with --hash-style=both this should indeed limit the damages.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpsm1LPpjSgf.pgp
Description: PGP signature


Reply to: