Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Sep 1998 01:35:09 +0200
From:      Martin Cracauer <cracauer@cons.org>
To:        Terry Lambert <tlambert@primenet.com>, David Dawes <dawes@rf900.physics.usyd.edu.au>
Cc:        mike@smith.net.au, jb@cimlogic.com.au, freebsd-current@FreeBSD.ORG
Subject:   Re: Standardizing a BSD/ELF ABI...
Message-ID:  <19980903013509.A12206@cons.org>
In-Reply-To: <199809020757.AAA24402@usr02.primenet.com>; from Terry Lambert on Wed, Sep 02, 1998 at 07:57:18AM %2B0000
References:  <19980902131453.C21469@rf900.physics.usyd.edu.au> <199809020757.AAA24402@usr02.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--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 <cracauer@cons.org> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980903013509.A12206>