From owner-freebsd-current@FreeBSD.ORG Thu Nov 27 03:41:19 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A82416A4CE for ; Thu, 27 Nov 2003 03:41:19 -0800 (PST) Received: from firecrest.mail.pas.earthlink.net (firecrest.mail.pas.earthlink.net [207.217.121.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 080EF43FAF for ; Thu, 27 Nov 2003 03:41:16 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-38lc14c.dialup.mindspring.com ([209.86.4.140] helo=mindspring.com) by firecrest.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1APKWD-0005KV-00; Thu, 27 Nov 2003 03:41:10 -0800 Message-ID: <3FC5E2DA.EC4B0345@mindspring.com> Date: Thu, 27 Nov 2003 03:41:14 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marcel Moolenaar References: <3FC40572.142D4334@mindspring.com> <20031126024927.GA7743@dhcp01.pn.xcllnt.net> <3FC49986.14E86B70@mindspring.com> <20031126173004.GB10589@dhcp01.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a498fc5fe065250522d77c7d2485b5ca1893caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: "E.B. Dreger" cc: current@freebsd.org Subject: Re: rtld + static linking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2003 11:41:19 -0000 Marcel Moolenaar wrote: > > Ether way, you still need to deal with the linker changes necessary > > to export the symbol set for all statically linked objects, and to > > force the inclusion of all archive members when statically linking, > > if one of the linked libraries is libdl, if you wanted a full > > implementation. > > I think the cure is worse than the decease in this case. You don't > want the full libc linked into a static sh, simply because we need > to be able to load a shared library at runtime. The alternative is to create a version association between the libc.a and libc.so, to allow it to be recovered at runtime. I don't know how satisfying this would be, but it would resolve 99.9% of the cases, I think. Arguing against inclusion of everything for all static libraris without a shared counterpart, and for the main program, is harder. For my money, it's a lot easier to dynamically link everything, and only deal with one type of executable image thereafter. > If you can get gcc and binutils to add the necessary support, then > we can talk further. Until then it's academic. I think there are political reasons for not doing this. The number one reason would be that you could load GPL'ed code as a module into a non-GPL'ed program, and then use it without neding to change your own license to GPL. Editorially, the FSF compiler folks have some incentive for making dlopen() inconvenient/difficult to use. If you link dynamic, at least they get the LGPL behaviour for all your other libraries as a consolation prize, so making it work is probably on their list of "Things To Not Do". If the Linux people want to be SUSv3/POSIX/IEEE 1003.1-2003 compliant, they'll do the work and FreeBSD will get it for free. If thy don't want to do the work, FreeBSD will have to decide whether they want to carry around local patches, or if the feature (killing off static vs. dynamic bikesheds) is worth the effort. I'm just offering a potential option that's not one of the two hotly contested ones, as a less controversial approach to a solution to the original problem. It's the solution that was chosen for the original problem that has everyone up in arms, so a different solution seemed to be called for here... > > BTW: IEEE 1003.1-2003 requires a full implementation of dlopen, and > > does not permit an exception for statically linked binaries: > > > > http://www.opengroup.org/onlinepubs/007904975/functions/dlopen.html > > Yes it does: > > \begin{quote} > ... Implementations may also impose specific constraints on the > construction of programs that can employ dlopen() and its related > services. > \end{quote} The phrase "constraints on the construction of programs" sounds to me like you're allowed to require compile options, not you're allowed to make it not work as it's documented to work otherwise, or we might as well say that calling dlopen() in a given system's implementation is allowed to invoke nethack, like the original GCC implementation of "#pragma" did. 8-). > > I'll also point out that the ELF specification does not define static > > linking *at all*. > > I think that's because it doesn't need any special mention. Well, it specifically mentions being able to do something like linking libc to libresolv, so that you implicitly get the resolver library when you explicitly link in the C library. That doesn't work with static linking of ELF binaries, so I think we can either say static linking is completely broken and needs to be fixed before it is allowed to be used, or static linking is undefined by the ELF standard. > Note that staticly linked executables can be in violation of platform > runtime specifications. A good reason to outlaw them: undefined behaviour sucks. -- Terry