Date: Mon, 29 Jan 2001 18:53:50 -0800 From: Peter Wemm <peter@netplex.com.au> To: arch@FreeBSD.org Subject: Re: libc_r badness Message-ID: <200101300253.f0U2ro459515@mobile.wemm.org> In-Reply-To: <200101291834.f0TIYL957823@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John Polstra wrote:
> In article <200101291811.f0TIBJ454801@mobile.wemm.org>,
> Peter Wemm <peter@netplex.com.au> wrote:
[..]
> > > 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 wit
h
> > 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.
Likewise, it scares the hell out of me too. Just try mixing up malloc()
from one libc with free() from another and see how far one gets..
Most of our troubles come from different dependencies of (custom) libperl
and zillions of shared objects. I have seen a bunch of places where programs
have ended up with libc.so.3 and libc.so.4 and it wasn't pretty. I believe
it pretty much worked but that was more due to luck than anything because
libc.so.3 we mostly used custom C++ libraries that used libc for little more
than syscall stubs.
Ironically, going the other way around seems to cause more failures. ie:
using a *later* version of a shared library (a 4.x binary - an interface to
a kld we use on our 4.x systems) with 3.x libraries and apps seems to cause
a lot more trouble than multiple libc's seem to. I do not remember the
problems too well, but if I recall correctly it was undefined symbols
(syscalls). It may have been solved by linking libproxyio.so against the
4.x libc.
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?200101300253.f0U2ro459515>