From owner-freebsd-hackers Tue Apr 22 19:28:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA26728 for hackers-outgoing; Tue, 22 Apr 1997 19:28:16 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA26723 for ; Tue, 22 Apr 1997 19:28:13 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA18646; Wed, 23 Apr 1997 11:53:21 +0930 (CST) From: Michael Smith Message-Id: <199704230223.LAA18646@genesis.atrad.adelaide.edu.au> Subject: Re: Dynamic linking libraries [Q] In-Reply-To: <199704222058.NAA27156@phaeton.artisoft.com> from Terry Lambert at "Apr 22, 97 01:58:15 pm" To: terry@lambert.org (Terry Lambert) Date: Wed, 23 Apr 1997 11:53:21 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, rssh@cki.ipri.kiev.ua, freebsd-hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > > > If you are referring to interprocess communication using static > > variables in a DLL, I think people here might be very ill. 8) > > I believe what he is referring to is that the MS executables put the > library-specific data segment into the DLL rather than statically > linking it with the program, as BSD does. Um, you are saying that if I link against a shared library, the .data segment from that library is linked into my executable at compile time? I honestly cannot believe that this is the case. eg. : cain:~/work/foo>cat testprog.c #include #include main() { printf("%s\n", sys_errlist[E2BIG]); } cain:~/work/foo>./testprog Argument list too long cain:~/work/foo>strings -n 8 testprog /usr/libexec/ld.so Couldn't open Failure reading ld.so Bad magic: ld.so Cannot map ld.so (text) Cannot map ld.so (data) Cannot map ld.so (bss) ld.so failed Service unavailable __DYNAMIC __exit_dummy_decl _dlclose _dlerror ___do_global_dtors ___DTOR_LIST__ ___CTOR_LIST__ ___do_global_ctors ___progname _sys_errlist __exit_dummy_ref _environ I certainly don't see the static data from libc there. > The biggest example in FreeBSD's sordid static data history is the > change in the handling of sys_errlist[], which might have been > entirely opaque between libc.so revisions, assuing the program itself > did not reference it (a bogus thing for a program to do anyway). > > If that were the case, a program which pulled the data in from the > shared library instead of pulling it into the program image at link > time would have continued to function. Instead, the entire FreeBSD > world blew up. I think you must be thinking of something else. > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[