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

Re: xpdf



On Sun, Jan 20, 2008 at 06:54:54PM +0000, Samuel Thibault wrote:
> Josh Triplett, le Mon 07 Jan 2008 21:36:59 -0800, a écrit :
> > Josh Triplett wrote:
> > > Josh Triplett wrote:
> > >> Samuel Thibault wrote:
> > >>> Josh Triplett, le Mon 07 Jan 2008 19:49:21 -0800, a écrit :
> > >>>> All of the stubs exist as weak symbols, so linking to pthread will
> > >>>> override the stubs in libpthread-stubs just like the ones in glibc.
> > >>> The big difference is that glibc is guaranteed to be dynamically loaded
> > >>> first, while libpthread-stubs is not necessarily, and this now have an
> > >>> influence on weak symbol overrides, see
> > >>>
> > >>> http://sourceware.org/bugzilla/show_bug.cgi?id=3946
> > >> Uh oh.  That looks bad for us too.
> > > 
> > > At least for Hurd, it looks like Debian's libc addresses your problem.
> > > According to /usr/share/doc/libc6/changelog.Debian.gz:
> > > 
> > > glibc (2.5-5) unstable; urgency=low
> > > [...]
> > >   [ Michael Banck ]
> > >   * patches/hurd-i386/local-dl-dynamic-weak.diff: new patch (turn
> > >     _dl_dynamic_weak on by default for hurd-i386).
> > > [...]
> > >  -- Aurelien Jarno <aurel32@debian.org>  Mon, 30 Apr 2007 21:55:09 +0200
> > > 
> > > That doesn't help libpthread-stubs, though.  And if, as the bug you
> > > referenced says, the ELF standards don't specify the behavior we expected
> > > for weak symbols, I don't know that we have a solution.
> > 
> > ...which apparently already got mentioned earlier in the thread.  Sorry for
> > the duplicate info; I should have read the entire thread before replying.
> 
> That said, now that you point out libpthread-stubs, maybe there's a
> not so bad solution: make libc0.3-dev depend on libpthread-stubs0-dev,
> and in libc.so, add AS_NEEDED ( /usr/lib/libpthread-stubs.so ) . That
> way, if a library uses pthread functions without including -lpthread,
> libpthread-stubs.so will automatically get linked in, providing the
> necessary stubs, and things will behave correctly when used either in
> a pthread program or in a non-pthread program.  The good thing in this
> compared to the solutions I proposed earlier is that we don't have to
> duplicate the work of libpthread-stubs, and when libpthread eventually
> gets included in glibc, we can easily know which packages need to be
> recompiled before putting back _dl_dynamic_weak to 0: it's simply all
> those which depend on libpthread-stubs0!

Sounds like a good solution to me.  Maybe we should test this a bit
though building and using a couple of applications.


Michael


Reply to: