32-bit X libs?

[Peter Jeremy]

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