Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Apr 2006 10:39:03 +0200
From:      Jeremie Le Hen <jeremie@le-hen.org>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: [fbsd] Re: [fbsd] Re: Symbol weirdness with static linking
Message-ID:  <20060421083903.GE68951@obiwan.tataz.chchile.org>
In-Reply-To: <20060421080216.GB1446@deviant.kiev.zoral.com.ua>
References:  <20060420114822.GB35261@obiwan.tataz.chchile.org> <20060420124829.GA1446@deviant.kiev.zoral.com.ua> <20060420221623.GD68951@obiwan.tataz.chchile.org> <20060421080216.GB1446@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
Kostik,

On Fri, Apr 21, 2006 at 11:02:17AM +0300, Kostik Belousov wrote:
> > > It seems that you rebuilt world with CFLAGS -fstack-protector,
> > > since your libc has references to the symbols like __stack_smash_handler.
> > > As result, when linking with sequence -lgcc -lssp -lc -lgcc -lssp,
> > > and no references from the main object,
> > > references from libc causes objects from _second_ instance of -lssp to
> > > be pulled into the link. Since libraries are scanned sequentially,
> > > this object from libssp has no way to get required dependencies
> > > from libc.
> > 
> > Yes, I understand that.  But I can't see what's the difference between
> > "syslog" and "sigfillset" symbols from this standpoint.  The fact the
> > former requires ProPolice/SSP doesn't interfere IMHO.
> > 
> > > What makes syslog(3) special is that corresponding object from libc,
> > > syslog.o, requires __stack_smash_handler, while objects for mentioned
> > > syscalls do not.
> > 
> > How does it prevent the "syslog" symbol from being found ?  Libc
> > undefined symbols implies the second libssp to be pulled in which in
> > turn has undefined symbol.  But since there is no more libc after this,
> > "sigfillset" should be missing either.
> > 
> > I would understand if echo.o needed some symbols provided by the same
> > archive than "sigfillset" (sigsetops.o) but this is not the case.
> > 
> You are absolutely right, my error. "Explanation" with syslog dependency
> on stack_smash is wrong. In fact, building bin/echo on CURRENT with
> -DNO_SHARED gives
> 
> deviant% objdump -t echo | grep sigfillset
> 08056dc0 g     F .text  00000021 sigfillset
> 
> It seems that at least the following dependency
> chain is present (for 6-STABLE):
> 
> malloc -> abort -> sigfillset,
> 
> and malloc is referenced by echo.
> 
> For CURRENT, (possibly, another) dependency also pulls
> sig* from libc.
> 
> Sorry for misinformation, I was innacurate when looking at issue.

There is no harm, don't bother.  I made me think some more on linking
mechanisms and I am more familiar with it now.

Thank you very much for your explanation.

Best regards,
-- 
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060421083903.GE68951>