Date: Mon, 29 Jan 2001 10:11:19 -0800 From: Peter Wemm <peter@netplex.com.au> To: arch@FreeBSD.ORG Cc: green@FreeBSD.ORG Subject: Re: libc_r badness Message-ID: <200101291811.f0TIBJ454801@mobile.wemm.org> In-Reply-To: <200101291745.f0THjTK57657@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John Polstra wrote: > In article <200101290419.f0T4Jnf09875@green.dyndns.org>, > Brian F. Feldman <green@FreeBSD.ORG> wrote: > > > Tell me, why can't libc_r depend on libc, and what good does libc_r > > do without libc? And, if libc_r is useless without libc, why can't > > it depend on libc automatically? I still see the same benefit of > > having libc be modular whether or not libc_r sticks it in the ELF > > library dependency section for its own use. > > Those automatic dependencies only work for dynamically-linked > programs. Statically-linked programs wouldn't be helped by this. There are two issues.. One is to have -lc_r on its own pull in libc to avoid POLA for apps that use ld(1) directly (doesn't work for static, no big deal). The second (seperate) issue is exising dynamic binaries on people's -current systems (eg: ports). Adding the LDADD+= -lc repairs the existing binaries that were linked with the old gcc specs and libc_r. I do not envy recompiling my handful of threaded apps. Not all are from ports. > Generally speaking, everything is useless without libc. Our > now-defunct temporary situation of using libc _or_ libc_r is the only > exception I'm aware of except for special-case stand-alone components > which don't execute in a normal program context. Since everything > needs libc, it is not recorded as an explicit dependency. Instead, > the compiler provides it automatically unless you ask it not to with > -nostdlib. Actually, there might be a good reason to do this.. (ie: add -lc_r) - it records the specific major version of libc that a program was compiled/ linked against. eg: libfoo.so.3 depends on libc.so.4 (old sigset). meanwhile you have libc.so -> libc.so.5 on your system and compile with the older -lfoo.. If libfoo.so.3 depended specifically on the older libc, then it will call sigaction() etc with the (old) sigsets that it (ie: osigaction) expects. The main program (having been linked against the new <signal.h> will be passing around new sigsets and will call sigaction in libc.so.5 with the new sigsets. Speaking from experience, we've had a lot of pain at yahoo over this implied dependency on "whatever version of libc that the calling program was linked against". I expect that having two versions of libc loaded wouldn't some new wrinkles, but it outright does not work without it. In a few cases we've used LD_PRELOAD and a few other hacks and relinks to get it to the point where we have several versions of a .so loaded and it works of sorts. (Yes, a recompile does follow, but we run into this when we have 4.x systems and infrastructure libs that have 3.x binary application packages pushed onto them). Anyway, that's something to think about. :-) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101291811.f0TIBJ454801>