Date: Wed, 14 Mar 2001 05:47:24 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: ken@kdm.org (Kenneth D. Merry) Cc: tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG Subject: Re: sbufs in userland, proposed solution Message-ID: <200103140547.WAA04393@usr05.primenet.com> In-Reply-To: <20010313220739.A93412@panzer.kdm.org> from "Kenneth D. Merry" at Mar 13, 2001 10:07:39 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > The "library A depends on library B" approach is _supposed_ to > > work with both static and dynamic linking. > > Outside the FreeBSD tree? Only if the objects are ELF objects. > From talking to John Polstra, it only works automatically with dynamic > linking. There are some makefile tricks to make it sort-of happen with > static linking (see the MINUSLPAM stuff in share/mk/bsd.libnames.mk) but > nothing that I know of that'll make the it work automatically. > > If there is a way to do it, I'd like to know how, since that would save me > from modifying all the ports that use libcam. There is supposed to be an ELF "depends on" section added to the dependent library, which the linker then uses to load the depended upon library. For dynamic libraries, this is handled by the ld.so doing the dirty work. In the static case, this is supposed to be done by ld, instead. I wouldn't be surprised if there was a bug here. The GCC people seem intent on abandoning static linking entirely, steadfastly leaving the system call ABI selector for Linux vs. FreeBSD vs. whatever, as "undefined", in the hope that people won't make it work anyway. Last time I checked, the bugs in ld were exactly the opposite way around: the link itself should force all symbols to be resolved (as in "RTLD_NOW"), but didn't flag links against libraries that depended on other libraries which weren't explicitly there, and for which there was not a dependency of the type you are making for the shared case (program A links against library B that calls a function defined by library C, but library C is not implicitly or explicitly called for, and the linker flags it on a static link, and fails only at runtime for a dynamic link). Fixing that particular ld bug was very, very hard. It might be easier now, but I ran into a couple of places where ld decided it was "OK" to forget symbol counting across several function calls at the same level. In any case, if it doesn't work with static, it's a violation of the specification, and needs to be fixed. My answer to the libresolv begin jammed into libc has always been to set up a library dependency, without any real symbol references, and let the linker follow the dependency to get the resolver functions from a libresolv. There are a lot of things you can fix by doing this, particularly if the linker "promotes" the library, and only uses the dependency as a factor when deciding precedence for symbol definitions to let users replace library functions with their own functions. It would mean a program linked dynamically on Linux would be able to run on FreeBSD, even though FreeBSD has different system call entry points, and FreeBSD has an implicit inclusion of a libresolv, while Linux has an explicit one (yes, before anyone jumps at me, I know that the manifest constant parameters and structures passed as arguments to the system calls would have to be the same for this to work, too). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200103140547.WAA04393>