32-bit X libs?

[Coleman Kane]

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.

Firefox links in a nice 37 .so's on my system. Just because
libX11.so.6, libXrender.so.1, libexpat.so.6, etc.., etc... have
native 64-bit versions installed doesn't mean that I can use them
with firefox 32-bit. I actually need to go through and build all
of these for a 32-bit system to install firefox into.

The reason you can still use the 64-bit version of du, or sh in your
programs is basically because the rtld is re-issued these commands to
create a new process space (and there is a barrier between your
32-bit program and the process loaded by execve, system, etc...).

Right now, we put the 32bit FreeBSD libs into 'lib32' counterparts
to our 'lib's. This is basically the same idea, but instead puts every
thing under a '32-bit' root and adjusts the search-paths accordingly
when the kernel realizes 'I am in ia32 and not amd64 space'.

> 
> >How about this... I will personally compile a list of needs for this
> >project.
> 
> - Re-mapping the rtld name on 32-bit executables
> - Re-mapping the shared library paths

This is already done with the lib --> lib32 builds.

> - Support installation of i386 ports
> - Support building of i386 ports (if I try to build a port that is only
>   for i386 or not for amd64 then it will automatically build as a i386)

I recommend this being a make option. Perhaps a general BUILD_ARCHS that
has a list of architectures to build? This way, the system could be
ported to FreeBSD/alpha, where i386 ports could be built by doing:
BUILD_ARCHS="alpha i386"
That would build the alpha and i386 versions of ports, while allowing
you to build the i386 version of i386 only ports, and the alpha version
of alpha-only ports. As you can see, the system would translate to amd64
quite well.

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.

> - 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. 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. That is, the
linuxulator first prepends /compat/linux to the search path for any
filesystem operation.

My further thoughts
-- ------- --------

I think that it would be worthwhile to have the ability for a system
admin to connect ports up to buildworld (if we want to allow such
things!). Perhaps allow ports to install to /usr/local/src (via a
make.conf option), and then make buildworld has a systematic way of
building add-ons from there via the make system. This way, a 
emulators/compat-ia32 could be put together to install a
/usr/local/src/emulators/compat-ia32 tree that would build the latest
/usr/src for IA32 when  buildworld was made.

This could also be transmitted to things like emulators/rtc,
graphics/dri, security/openssl, security/openssh when the admin wishes
to tie these ports in (and they might have depedencies on the system 
that get borked when tracking a non-release CVS branch). This is 
especially helpful in the cases where *_OVERWRITE_BASE has been chosen.

Sounds complicated? of course it does.

On the ports side of things...
-- --- ----- ---- -- ---------

I think that we want to offer two options:
1) Allow someone to build for all of the architectures specified in a list
2) Allow someone to specify a list of architectures to step through, and
   build the first architecture that the port allows

This solves the problems of not wasting a bunch of space and time
building every architecture for every port. But, it will allow some
people (like those who want ia32 and amd64 firefox).

Libraries, libraries...
---------- ------------

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. Allowing the built 32bit libc to be a shell that
implements 32-bit versions of "non-substitutable functions" and calls
through to the 64-bit libc.so for the "substitutable functions", all
defined at build time. If I am not mistaken, the 64 bit code should be
able to address the 32-bit code's memory, but not the other way around,
which is why things like 32-bit flash in firefox/amd64 is much more 
difficult than you would first think, considering we have linux-flash
working in firefox/i386.

Oh yeah... there's likely more that I haven't covered.

> 
> -- 
> Peter Jeremy

--
Coleman Kane