Date: Mon, 29 Jan 2001 10:34:21 -0800 (PST) From: John Polstra <jdp@polstra.com> To: arch@freebsd.org Cc: peter@netplex.com.au Subject: Re: libc_r badness Message-ID: <200101291834.f0TIYL957823@vashon.polstra.com> In-Reply-To: <200101291811.f0TIBJ454801@mobile.wemm.org> References: <200101291811.f0TIBJ454801@mobile.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <200101291811.f0TIBJ454801@mobile.wemm.org>, Peter Wemm <peter@netplex.com.au> wrote: > John Polstra wrote: > > > > Those automatic dependencies only work for dynamically-linked > > programs. Statically-linked programs wouldn't be helped by this. > > There are two issues. You raise some good points. > 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. OK, I misunderstood the goal when I replied before. I can see that it would be helpful to have libc_r depend explicitly on libc in order to make existing binaries work again. > > 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. Have you actually used this much, i.e., having two different libc.so.* versions loaded into the same program image? I am not sure that it won't work, but it gives me mild heart palpitations to think about it. We have pretty good symbol scoping now inside the dynamic linker, but still it seems like there is a lot of potential for strange behavior which would be very hard to diagnose. For example, malloc uses some static variables to keep track of things. If there are two libcs then there are two mallocs and two sets of those variables. It seems like there's potential for them to step on each other's toes. Again, I haven't proved that it won't work, but I have a feeling there would be cases where it would fail in very confusing ways. Our current method of linking things at least guards against having multiple libc versions that might interfere with each other. > Anyway, that's something to think about. :-) I agree it's worth thinking about. I'm just worried that it could seem to work at first, and then we'd discover horrible world problems a few weeks down the line that might be hard to recover from. Mr. Worry Wart -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa 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?200101291834.f0TIYL957823>