Date: Wed, 8 Feb 2006 05:36:08 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Coleman Kane <cokane@cokane.org> Cc: freebsd-amd64@freebsd.org Subject: Re: 32-bit X libs? Message-ID: <20060207183608.GC699@turion.vk2pj.dyndns.org> In-Reply-To: <20060206194532.GA17347@pint.candc.home> References: <346a80220602032210o71367220v74033da94e3d83bb@mail.gmail.com> <XFMail.20060204144751.conrads@cox.net> <346a80220602051652u5b5f59fdx5fc715c22b84d133@mail.gmail.com> <20060206184111.GE699@turion.vk2pj.dyndns.org> <20060206194532.GA17347@pint.candc.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2006-Feb-06 14:45:32 -0500, Coleman Kane wrote:
>On Tue, Feb 07, 2006 at 05:41:11AM +1100, Peter Jeremy wrote:
>> On Sun, 2006-Feb-05 19:52:30 -0500, Coleman Kane wrote:
>> >Alright. I like the /usr/compat/ia32 idea as well.
>>
>> It would be even nicer if it was totally transparent so no compat
>> hierarchy was needed. The name should probably be /usr/compat/i386 in
>> keeping with the FreeBSD naming convention. One difficulty in
>> handling /usr/compat/ia32 is applications like mozilla and
>> OpenOffice.org which have front ends comprising to twisty maze of
>> shell scripts with the actual executables buried elsewhere. (And in
>> the case of mozilla, it may be reasonable to have both 32-bit and
>> 64-bit versions installed).
>
>Problem is this: all your 32-bit apps require 32-bit library
>counterparts for everything that they link against. For instance,
>lets pretend that firefox wouldn't work on amd64.
I'm aware of that. I expressed myself very poorly. What I meant to
say was that that it would be nice if the kernel and rtld could
automatically map between .../lib and .../lib32 depending on the ELF
type, rather than requiring that all 32-bit code lived in
.../compat/ia32. We also need the ability for a 32-bit app to exec a
64-bit app (whereas I believe the Linux compatibility layer required
that an exec'd process always be inside the .../compat/linux tree).
A (Linux enthusiast) friend was mentioning that Linux has .../lib and
.../lib64 in its amd64 variant. Solaris does much the same. I
suspect that one reason for naming things this was round is that it
vastly simplifies handling compatibility issues - basically, 32-bit
apps just run (because they always point to the 32-bit RTLD and
libraries), whilst 64-bit apps get compiled to point to the 64-bit
versions. It's too late now, but this probably should have been done
on FreeBSD as well. (The downside is that it makes the 'native'
architecture look like 32-bits, with 64-bits as an addon). OTOH,
a 32-bit app is always going to be smaller and, with less memory
footprint, possibly faster - therefore is makes a degree of sense to
only use 64-bits where it is needed (eg accessing lots of memory,
doing lots of multi-precision integer arithmetic).
>Revisiting my earlier comment, we'd also need to maintain seperate
>/var/db/pkg trees as well. You only want to have the necessary libs
>build in 32bit to support your chosen set of 32bit ports. You'll need a
>seperate pkgdb to keep track of them all.
Good point. But it gets nastier when dealing with dependencies.
LIB_DEPENDS will (always, I think) need to be the same ARCH.
BUILD_DEPENDS and RUN_DEPENDS may or may not need to be the same ARCH.
Things like {d,g,i}make, gm4 etc don't care whether they are being
used to build 32-bit or 64-bit apps.
Perl is messier - if perl is just being used to run configuration or
installation scripts, its ARCH doesn't matter. If you're building a
perl module it probably doesn't matter, unless the module itself
contains some binary component that isn't ARCH-independent.
>> - allow me to mount FreeBSD/i386 filesystems and execute programs in them.
>
>Correct me if I am wrong, but there is no such thing as a
>"FreeBSD/i386 filesystem". The Berkeley FFS is the same across i386,
>amd64, alpha, sparc64, ppc, and whatever else.
Yes.
> The only thing there is
>is a "FreeBSD FFS with i386 programs on it", which would fall under the
>same sort of rules that the linuxulator uses right now.
This is what I was referring to. It I mount my FreeBSD/i386 filesystems
on my FreeBSD/amd64 box, then they mostly fail to load the correct shared
libraries (though I think I need to re-evaluate this - the ldconfig32
hooks I thought I had are only in my -current FS and I was testing on
-stable).
>I think that it would be worthwhile to have the ability for a system
>admin to connect ports up to buildworld
I think this is work for much later.
>I have an idea how infeasible this is, but it would be cool to be able
>to specify library mappings from 32-bit land to 64-bit land. Say, for
>instance, the amd64-bit versions of the libc string functions are faster
>than the 32-bit libc ones.
AFAIK, this won't work. amd64 and i386 code is not compatible. The
amd64 CPU can be told that a particular process (task descriptor) is
to be executed in "compatibility mode" but I don't believe it's possible
to switch between them at runtime.
--
Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060207183608.GC699>