From owner-freebsd-current Sun Jan 19 21:35:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA11970 for current-outgoing; Sun, 19 Jan 1997 21:35:07 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA11949; Sun, 19 Jan 1997 21:34:56 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.3/8.8.3) with ESMTP id VAA25350; Sun, 19 Jan 1997 21:34:46 -0800 (PST) Message-Id: <199701200534.VAA25350@austin.polstra.com> To: Mark Murray Cc: peter@FreeBSD.org, current@FreeBSD.org Subject: Re: Static binaries and dlopen(3) with a new crypt(3) lib. Date: Sun, 19 Jan 1997 21:34:46 -0800 From: John Polstra Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > 1) Peter did some mods to crt0 that seemed to hint that this would > work even for static binaries. I cannot duplicate his success. I > have a bit of test code (see enclosure) which I link like this: > > $ cc -Wall -Wl,-Bstatic -o main main.c > > It works if I leave out the -Wl,-Bstatic bit (to make it all > dynamic). Any clues? The change Peter made was that dlopen() and related functions no longer come up undefined under static linking. But they're just stubs, and they always return an error. It's hard to support dlopen() under static linking, because the dynamic linker isn't even present in the address space. It's not impossible, just nontrivial. I've been meaning to look into it for a while. Maybe this will get me moving. > One of the problems - libraries have this nice, automatic way of > looking at version numbers (.so.N.M), whereas in dlopen(3), one > must supply a name (hardcoded?). Since dlopen() takes a "mode" parameter, I could easily add a new flag bit for it that would cause dlopen() to follow the usual library search rules. I also want to move the dl* functions out of crt0.o, where they pollute the namespace and cannot be overridden by user functions of the same name. From a brief look, I don't see any reason that they can't be moved into libc. They do need a tie-in to crt0.o, but they don't have to be defined there. I mention this because I wouldn't want to add any new global functions to crt0, but I wouldn't feel so bad about adding them to libc, where they can be overridden. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth