Date: Fri, 08 Feb 2002 10:45:23 -0800 From: Bakul Shah <bakul@bitblocks.com> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: Terry Lambert <tlambert2@mindspring.com>, Ruslan Ermilov <ru@FreeBSD.org>, Jason Evans <jasone@canonware.com>, jdp@FreeBSD.org, deischen@FreeBSD.org, jasone@FreeBSD.org, hackers@FreeBSD.org, jlemon@FreeBSD.org Subject: Re: Linking libc before libc_r into application causes weird problems Message-ID: <200202081845.NAA13569@glatton.cnchost.com> In-Reply-To: Your message of "Fri, 08 Feb 2002 20:03:22 %2B0200." <3C6412EA.2605CDB@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> As you can see from my log there was no library explicitly linked with
> libc and no -lc command line option, but resulting executable ended up
> with libc recorded right before libc_r. Any clues?
I don't get this ordering problem with your test.c file on a
very recent -current. What do you get when you use the -v
flag (not for the test case but the program (ximian) that hangs)?
By using the -v flag as in
$ cc -v test.c -o test -lc -lc_r
reveals (after snipping uninteresting stuff)
/usr/libexec/elf/ld -m elf_i386 -dynamic-linker /usr/libexec/ld-elf.so.1 -o test /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/libexec/elf -L/usr/libexec -L/usr/lib /tmp/cc6O0HGi.o -lc -lc_r -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o
$ ldd test
test:
libc.so.5 => /usr/lib/libc.so.5 (0x18068000)
libc_r.so.5 => /usr/lib/libc_r.so.5 (0x1811b000)
Here ./test hangs. Based on the follow
But
$ cc -v test.c -o test -lc_r -lc
reveals
/usr/libexec/elf/ld -m elf_i386 -dynamic-linker /usr/libexec/ld-elf.so.1 -o test /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/libexec/elf -L/usr/libexec -L/usr/lib /tmp/ccrxO4nI.o -lc_r -lc -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o
$ ldd test
test:
libc_r.so.5 => /usr/lib/libc_r.so.5 (0x18068000)
libc.so.5 => /usr/lib/libc.so.5 (0x18086000)
Here ./test does not hang.
So it is clear that the cc frontend sticks on -lc at the end.
To prove it:
$ cc -v test.c -o test -lc_r
reveals
/usr/libexec/elf/ld -m elf_i386 -dynamic-linker /usr/libexec/ld-elf.so.1 -o test /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/libexec/elf -L/usr/libexec -L/usr/lib /tmp/ccxNFUZi.o -lc_r -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o
ldd test
test:
libc_r.so.5 => /usr/lib/libc_r.so.5 (0x18068000)
libc.so.5 => /usr/lib/libc.so.5 (0x18086000)
and ./test works.
Also note that on 4.5-RELEASE, ./test core dumps where it
hangs on -CURRENT so there too it misbehaves but differently.
Elsewhere you said
> I think that ld(1) should be smart enough to reorder libc/libc_r so that
> libc_r is always linked before libc.
I don't believe this would be wise. ld should do exactly
what it is told and link against libraries in the order
specified. It is the frontend's (cc's) repsonsibility to
specify libraries in the right order. I do think that
explicitly specifying libc or libc_r to cc is asking for
trouble (though I understand your doing it in a test case to
illustrate the problem).
-- bakul
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202081845.NAA13569>