From owner-freebsd-hackers Fri Feb 8 10:45:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from glatton.cnchost.com (glatton.cnchost.com [207.155.248.47]) by hub.freebsd.org (Postfix) with ESMTP id 360F537B428; Fri, 8 Feb 2002 10:45:24 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by glatton.cnchost.com id NAA13569; Fri, 8 Feb 2002 13:45:23 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200202081845.NAA13569@glatton.cnchost.com> To: Maxim Sobolev Cc: Terry Lambert , Ruslan Ermilov , Jason Evans , 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 In-reply-to: Your message of "Fri, 08 Feb 2002 20:03:22 +0200." <3C6412EA.2605CDB@FreeBSD.org> Date: Fri, 08 Feb 2002 10:45:23 -0800 From: Bakul Shah Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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