From owner-freebsd-current Wed Sep 2 16:36:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA28192 for freebsd-current-outgoing; Wed, 2 Sep 1998 16:36:34 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from gilgamesch.bik-gmbh.de (gilgamesch.bik-gmbh.de [194.233.237.91]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA28159 for ; Wed, 2 Sep 1998 16:36:26 -0700 (PDT) (envelope-from cracauer@gilgamesch.bik-gmbh.de) Received: (from cracauer@localhost) by gilgamesch.bik-gmbh.de (8.8.8/8.7.3) id BAA12214; Thu, 3 Sep 1998 01:35:10 +0200 (MET DST) Message-ID: <19980903013509.A12206@cons.org> Date: Thu, 3 Sep 1998 01:35:09 +0200 From: Martin Cracauer To: Terry Lambert , David Dawes Cc: mike@smith.net.au, jb@cimlogic.com.au, freebsd-current@FreeBSD.ORG Subject: Re: Standardizing a BSD/ELF ABI... References: <19980902131453.C21469@rf900.physics.usyd.edu.au> <199809020757.AAA24402@usr02.primenet.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=wRRV7LY7NUeQGEoC X-Mailer: Mutt 0.93.1i In-Reply-To: <199809020757.AAA24402@usr02.primenet.com>; from Terry Lambert on Wed, Sep 02, 1998 at 07:57:18AM +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii In <199809020757.AAA24402@usr02.primenet.com>, Terry Lambert wrote: > > Is there compatibility for dynamically linked executables when using the > > runtime host platform's native libraries? > > Yes and no. > > ELF supports the idea of multiple, seperate data segments. > > Using this construct, one can finally build shared libraries where > the data section of a shared libraries static, initialized data > comes from the dynamically linked shared library in the load phase > rather than the link phase. > > If you want to get into details: any program distribured for Linux > at this time FAILS the LGPL relink clause because the data segment > is linked into the program image from the shared library at the > time the program is linked, and runtime relinking applies only to > code, not to data. > > It is easy to implement a data-content dependent example of a > library that fails the LGPL relink clause because of this. > > Techinically, one need only increase the size of a statically > initialized data area. Are you sure about this? The appended tarfile contains two implementations of a shared library, one with more statically initialized data and some variables in different order, besides different initial values for all variables. On FreeBSD-2.2.7-stable and Linux (Debian-1.3) this gives correct results. I have not been able to reproduce a case where data from the library I linked against is used instead of data from the .so file that happens to be in place when the program runs. See the 'make run' target. I also tried to push the amount of extra data in test2a.c to more than 32K, but the result was still correct. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer BSD User Group Hamburg, Germany http://www.bsdhh.org/ --wRRV7LY7NUeQGEoC Content-Type: application/x-tar-gz Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="link.tar.gz" H4sIAO4y7TUAA+1cT2/bNhRX1q6IiB12GHbagXDTIsliVaT+tdE6eEu3ocAGDCsw7DBgkGWm FiLLhiQXHYZ+m32E3Xfc11mQ+7BH6o9l2W5SNJLilj8glfj4+CiRfL/3REsNg+jsgdIssKk7 loUVjDFxiDhi7ORHAR1j23IMahDDNEFLNy1DwVbD1yUwT1IvxljxY8/35izepDcMojYup22E fP5TlqTauLE+iK7bMK0b55/YJJ9/6tgUzgmxbaJgvbErquA9n3/2MmVxhP0xDMIhXwe/ZRIX BVGKuSAoJSjTGobe/otpMDpwFwJaSHgrKAf1cqnQ9Q1LLEH4/08nz5qMAW/A/zpxdO7/umNL /m8D5fz/4J2x0yBkRy+uvQ/gf/M1/E+pXZl/WCiYGGL+Jf83jzHzRirRiIs832dJ4qLk98lw GsJJOPXPEqQWA3PMtXCSxoGfAvNPJxMWpergLh5AZEBQiUZeytRHDzX9kaZTjRDNdDTLcVVv no6nMS4MuSoMecrwNy9nLhrGXuSPGXQXQZhRuakRS3w0ONxRlI+U2zsaXOSnijj/QIMCBvnH yu6dPGf592+Fl2/fgjWsaFPl3Mnqb6WTmcL/PofyE2V3t1jfSnj/goLsE5BxG8SDViAzQPZZ IRtmMn5O4fQ/ZUnfV77cuzio2hiCDPT7FRn1MpleleV6BGR7O7t3Jl4QgUTcwxeFLS2ZKv/c v7CWbYnrsZdtCdlRVcbbgkzLxuBDbp8oR+cmlP/KyxTKD6H8J4whBGbe4rzTFbgBaJCvqnD6 HA00KKawQNDg5Nvvv/ru2WNV7Z/OAh/3n/z49AQhLwyPcTF8uBgLLAZA/EvBWlGfa8Kg4mK2 kfrcB2MJ5DNshPu/cFpkMe5/LSTeMGS4P8V7g8GapqjoLrNLi0r6xnaXmyJx9cfi8ov+oJfc ZPXmqrWiFV1qReut6Eot8kPmRcdI7ccTfAg1h7Xhw+BLCMXzaOV6Kl34s4U0W1tlt9C8aFjU hKORsKpqD8Qhb02rrWs6A5k+XjPK+J9xUQPR/9L4T2ynHv+pZVAZ/9vAW8d/fCgTAJkANIBN CcDdIPLD+YjhXrYCekhsMvBby/YY0B8I41kMwtP9HtwhPsb3kl+j3hGPKvsHB+5yNa1W01p9 tvVRalQ2SOpmAt7NqLATrPYT0CWF9T0FpU5160UoxiydxxHWXfTqGuNgyf/ZYHbC/6ZpVfjf FvzvGJL/24Dkf8n/28X/re9Yv9MPHUv8z5d2+/t/xDGMGv/DUZf83wYk/0v+3y7+X5P/8+UU +NWQkEse495Tf4zBdzELIob5/PcTfzpj+GcvDsT+mzdPsl2rnlsYWgSS0g5ZDSbiOSPPyiud 8vx8Jcys6BYR6hWqBaC6ZlA1W4tNq7oLs1eMWsv8P+yE/02jnv9L/m8Lkv8l/289/688C6wQ fybewPr154ac7t/pvL/AEv/TG5T/y/e/WoHkf8n/W8//15L/09fm//R9yP9pV/m/KfP/jiD5 X/L/1vP/W+T/dH3+T9/xbf8Sgv9L12gGl33/4TiV/J8a/Pdf0JP83wa6fZ2yobcp5cuUV3mZ Usx/+f2XCGvN4DL/N02n9H/dFv6vO470/zYgf0250tNU19PUGBb+P+zM/4m1+P7T0Wnm//L7 n1bQ2m561zcqsRal/9Pu4r9l0jL+m7Yj8n/dlP7fBjbH//WboJXKeTRP2Mi9vt3X7UoJ0GIM Tle1i8G56anDwv+7jP/6Iv6T7Plfl/u/raCt3bSu71NiPYT/59vQTeHS53998fuPTsX//2DL +N8O5NdUNz1CS0hISDSD/wFUGhoaAFAAAA== --wRRV7LY7NUeQGEoC-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message