Date: Fri, 28 Oct 2005 16:25:05 +0200 From: Ulrich Spoerlein <q@galgenberg.net> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: emulation@freebsd.org Subject: Re: Porting linux-wine Message-ID: <20051028142505.GC1126@galgenberg.net> In-Reply-To: <20051028154859.6xvaydvtes88gows@netchild.homeip.net> References: <20051026123347.GA1054@galgenberg.net> <20051026150705.qzo2u74dgggcosss@netchild.homeip.net> <20051026133312.GB1054@galgenberg.net> <20051027100016.qpwre4w60woo088c@netchild.homeip.net> <20051027083827.GA1070@galgenberg.net> <20051027165956.yplku4x8gw804osc@netchild.homeip.net> <20051027151458.GC1070@galgenberg.net> <20051028085130.4wa89yr8ooowkck8@netchild.homeip.net> <20051028100044.GB1126@galgenberg.net> <20051028154859.6xvaydvtes88gows@netchild.homeip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--/3yNEOqWowh/8j+e
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, 28.10.2005 at 15:48:59 +0200, Alexander Leidinger wrote:
> [error]
>=20
> You said you branded *all* libs, but libtermcap is still unbranded... is
> there anything obvious which I overlooked?
Yes, the list I grepped was made _before_ branding. I just wanted to
show, that it worked before branding, as it had brand 0. Then after
branding to 3 it stopped working. But see below.
> [libtermcap]
> >It was one of the non-branded libs. So, is branding everything
> >considered bad practice?
>=20
> In an ideal Ports Collection, every ELF object which is supposed to be a
> linux object, is branded as such.
Better not! I just found out, that even ICC, which isn't even installed
in /compat/linux will not run, after branding all libs
/usr/local/intel_cc_80/bin/icpcbin: error while loading shared libraries: /=
lib/libm.so.6: ELF file O
S ABI invalid
*** Error code 127
> A static linux binary has to be branded, else you will shoot yourself in =
the
> foot (it may cause the system to reboot or do other things you don't want=
to
> happen). A shared linux ELF object may work as intended, but if you want =
to
> do it properly, you have to brand them. I vote for doing it properly.
I was thinking along the same lines, but there's obviously something
wrong with this approach, as nearly all linux-apps stopped working here.
> The "find ... brandelf" line is from the linux_base-8 port, althought I o=
nly
> brand files in /{,usr/}{,s}bin there... obviously it needs to be extended
> (not only in the linux_base-8 port). Patches are welcome.
I think I can explain why things don't work and the culprit seems to be
/lib/ld-linux.so.2 which won't load libs when they are branded with type
3.
Observe.
% /compat/linux/usr/bin/djpeg
Empty input file
(1)% file /compat/linux/usr/bin/djpeg
/compat/linux/usr/bin/djpeg: ELF 32-bit LSB executable, Intel 80386, versio=
n 1 (SYSV), for GNU/Linux 2.0.0, dynamical
ly linked (uses shared libs), stripped
% ldd /compat/linux/usr/bin/djpeg
/compat/linux/usr/bin/djpeg:
libjpeg.so.62 =3D> /usr/lib/libjpeg.so.62 (0x48060000)
libc.so.6 =3D> /lib/libc.so.6 (0x48083000)
/lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x4804d000)
% brandelf /compat/linux/usr/bin/djpeg
File '/compat/linux/usr/bin/djpeg' is of brand 'SVR4' (0).
% brandelf /compat/linux/usr/lib/libjpeg.so.62
File '/compat/linux/usr/lib/libjpeg.so.62' is of brand 'SVR4' (0).
Everything working so far.
% sudo brandelf -t Linux /compat/linux/usr/lib/libjpeg.so.62
% ldd /compat/linux/usr/bin/djpeg
/compat/linux/usr/bin/djpeg:
/compat/linux/usr/bin/djpeg: error while loading shared libraries: /usr/lib=
/libjpeg.so.62: ELF file OS ABI invalid
/compat/linux/usr/bin/djpeg: exit status 127
(1)% /compat/linux/usr/bin/djpeg
/compat/linux/usr/bin/djpeg: error while loading shared libraries: /usr/lib=
/libjpeg.so.62: ELF file OS ABI invalid
(127)%
The way I see it (and I don't know nothing about ELF and shared
libraries), the Linuxulator loads the branded binary, ok. Then
ld-linux.so.2 kicks in and tries to load all necessary shared libraries.
But it will only load them, if their brand is '0' (as that is what Linux
uses). So when it encounters a lib with a brand of '3' it will error
out.
Does this make sense? If so, there a two possible fixes:
1) Tell the Linux folks to fix their ld-linux.so so it accepts brand 3
(is this standardized? Or did the FreeBSD Project make up the number
'3' here?). Then wait for it to become available in the next
linux_base and brand *all* binaries and libs.
2) Brand all binaries, that can/will be called directly from FreeBSD.
Don't touch any libs that ld-linux.so could possibly load.
I then even made some progress with wine. Branding the binaries only I
got this:
wine: failed to initialize: /usr/lib/wine/ntdll.dll.so: failed to map segme=
nt from shared object: Cannot allocate memory
which is probably due to the tricks wine plays with the heap. Perhaps,
after all, linux-wine can never possibly work on FreeBSD?
Ulrich Spoerlein
--=20
PGP Key ID: F0DB9F44 Encrypted mail welcome!
Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44
Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
didn't you understand?
--/3yNEOqWowh/8j+e
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
iD8DBQFDYjTBmArGtfDbn0QRArhrAKD+GEwxkJ1G3cmaSunExO8Hb2YIPwCfR+0L
pWTJhLN/QeiRinXQAZ2A6qg=
=ogzq
-----END PGP SIGNATURE-----
--/3yNEOqWowh/8j+e--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051028142505.GC1126>