Re: [fbsd] Re: Symbol weirdness with static linking
- From: Kostik Belousov <kostikbel@xxxxxxxxx>
- Date: Fri, 21 Apr 2006 11:02:17 +0300
On Fri, Apr 21, 2006 at 12:16:23AM +0200, Jeremie Le Hen wrote:
Hi, Kostik,You are absolutely right, my error. "Explanation" with syslog dependency
For the sake of completeness, I added the output of some objdump(1)
outputs here :
/usr/obj/usr/src/bin/echo/echo.o:
http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_echo.txt.gz
/usr/obj/usr/src/tmp/usr/lib/libc.a:
http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_libc.txt.gz
/usr/obj/usr/src/tmp/usr/lib/libssp.a:
http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_libssp.txt.gz
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.
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.
Attachment:
pgpMwPp6rYvyy.pgp
Description: PGP signature
- Follow-Ups:
- Re: [fbsd] Re: [fbsd] Re: Symbol weirdness with static linking
- From: Jeremie Le Hen
- Re: [fbsd] Re: [fbsd] Re: Symbol weirdness with static linking
- References:
- Symbol weirdness with static linking
- From: Jeremie Le Hen
- Re: Symbol weirdness with static linking
- From: Kostik Belousov
- Re: [fbsd] Re: Symbol weirdness with static linking
- From: Jeremie Le Hen
- Symbol weirdness with static linking
- Prev by Date: Re: [PATCH] Fancy rc startup style RFC - v6
- Next by Date: Re: [fbsd] Re: [fbsd] Re: Symbol weirdness with static linking
- Previous by thread: Re: [fbsd] Re: Symbol weirdness with static linking
- Next by thread: Re: [fbsd] Re: [fbsd] Re: Symbol weirdness with static linking
- Index(es):
Relevant Pages
- Re: [fbsd] Re: [fbsd] Re: Symbol weirdness with static linking
... references from libc causes objects from _second_ instance of -lssp to ...
undefined symbols implies the second libssp to be pulled in which in ... archive than "sigfillset"
but this is not the case. ... (freebsd-hackers) - Re: [fbsd] Re: Where is thr_getscheduler
... References to symbols in libthr.so.2 are satisfied by default ... libc symbols
is absent in the shared libraries. ... In this post Warner Losh states that doing
so would solve some ... (freebsd-current) - Re: [fbsd] Re: Symbol weirdness with static linking
... references from libc causes objects from _second_ instance of -lssp to ...
undefined symbols implies the second libssp to be pulled in which in ... archive than "sigfillset"
but this is not the case. ... (freebsd-hackers) - Re: [fbsd] Re: Symbol weirdness with static linking
... references from libc causes objects from _second_ instance of -lssp to ...
Since libraries are scanned sequentially, ... Best regards, ... (freebsd-hackers)