Date: Sun, 2 Dec 2007 03:30:10 +0200 From: Nikos Ntarmos <ntarmos@ceid.upatras.gr> To: freebsd-hackers@freebsd.org Subject: Re: Linux executable picks up FreeBSD library over linux one and breaks Message-ID: <20071202013010.GA6198@ace.netcins.ceid.upatras.gr> In-Reply-To: <20071201230022.R74097@fledge.watson.org> References: <1196470143.4750af7f6accf@webmail.rawbw.com> <20071201162930.5c9fd4dd@deskjail> <20071201230022.R74097@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, Dec 01, 2007 at 11:01:46PM +0000, Robert Watson wrote:
>
> On Sat, 1 Dec 2007, Alexander Leidinger wrote:
>
> >Have a look at the search order of libs in linux. Correlate this with
> >the fact that when in linux an access is done to e.g. /lib/libX.so.y
> >which means that the linuxulator first looks if
> >/compat/linux/lib/libX.so.y is there, and if it isn't it looks if
> >/lib/libX.so.y is available.
> >
> >AFAIR a work around is to add a link in
> >/compat/linux/usr/lib/librt.so.1 -> /lib/librt.so.1
> >
> >I want to do something like this in the FC4 port, but hadn't time to
> >do it and test it so far.
>
> It sounds like the real problem is that there are some cases where we
> don't want the Linuxulator to merge the underlying and Linux views of
> the file system -- we don't want the union of /compat/linux/lib and
> /lib, we just want /compat/linux/lib?
The problem mainly arises when a library appears earlier in the search
path in the underlying view of the file system than in the Linux view.
(e.g. there is no /compat/linux/path1/lib/libX.so.y but there is a
/path2/libX.so.y and path2 appears before path1 in the ld search path).
X-related libraries are a good example; since we moved to a
${LOCALBASE}-based X hierarchy, all X-based dynamically-linked linux
binaries pick up the native X libraries (i.e. from /usr/local/lib),
unless advised otherwise (e.g. via
LD_LIBRARY_PATH=/compat/linux/usr/X11R6/lib:$LD_LIBRARY_PATH).
Symbolic links do work. Another solution is to rearrange dynamic
libraries under /compat/linux so that they match the FreeBSD hierarchy
(and teach ld-linux to use the same search path as the native loader).
And yet another solution is to teach the linuxolator to first do an
exhaustive search for libraries under /compat/linux and only then fall
back to native ones (this seems similar to the above LD_LIBRARY_PATH
incantation).
Just my $0.02.
\n\n
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Nikos Ntarmos <ntarmos@ceid.upatras.gr>
iD8DBQFHUgqim6J1ac+VFgoRAunbAJ4/zMkaKVO4Nuu5ddyjww1WIzdtQACeOq7C
i4a+uIyjPXAHfghAhfOgs9M=
=qKI+
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071202013010.GA6198>