[arch-dev-public] Multilib on Archlinux x86_64
Thomas Bächler
thomas at archlinux.org
Tue Jul 8 13:43:39 EDT 2008
For a while now, there have been lib32-* packages in community. They
sort of work for many applications, but have certain problems. This is
what I don't like about them:
- The naming convention (lib32-*)
- The separate prefix (/opt/lib32)
- The fact that the binaries are only copied from the 32 bit packages
One can argue about the first two, but the third poses a real problem:
Many libraries have hardcoded paths to plugin directories, like
/usr/lib/gconv in glibc. If you run the glibc binary from arch32 in a 64
bit environment, glibc looks in /usr/lib/gconv for plugins, but only
finds 64 bit binaries, which it can't load. Similar problems exist for
many other libraries. Some can be worked around with environment
variables, which is annoying, some can't. Thus, a clean solution is to
rebuild all required binaries with the right paths included.
I am proposing to build a new repository, let's call it [multilib] for
now, which only exists on x86_64. I strictly want this to be separate
from [extra], to keep our main repositories clean (however, extensions
to [multilib] can still be placed in [community] IMO).
GOALS:
Fill in the missing pieces on x86_64:
- flash
- wine
- possibility to install skype, teamspeak and google-earth from AUR
Build all necessary libraries to install all of the above, but not more
than that.
APPROACH:
The idea is to only install a 32 bit runtime, no complete toolchain.
Packages are being built on a full 32 bit Archlinux system in the
following way:
The package is renamed from foo to foo-32bit (that's the naming
convention I like most). All libraries are installed in /usr/lib32, only
libraries are installed. It may be necessary to install exectuables,
those should be put into /usr/bin in a way that they don't conflict with
the normal 64 bit packages. If a library needs data files (for example
in /usr/share), the package depends on the corresponding 64 bit package.
makepkg must be fooled into marking the package as x86_64. This can be
done by putting 'export CARCH="x86_64"' to the end of the build()
function, but this is unclean (breaks with -L, possibly more). I am
using a patched makepkg (not upstream yet) to introduce a 'destarch'
keyword for the PKGBUILD (destarch='x86_64').
A package that can only exist in a 32 bit environment may put files into
/usr/{bin,share,man,...} (but not include/), as there will never be
conflicts with 64 bit packages (for example, wine will create
/usr/{bin,share}/wine). Libraries must still be installed in /usr/lib32.
To make all those packages work, glibc-32bit installs a symlink
/lib/ld-linux.so.2 -> /usr/lib32/ld-linux.so.2. This is no problem
because the 64 bit linker is called /lib/ld-linux-x86-64.so.2 (or
/lib64/ld-linux-x86-64.so.2 in non-archlinux binaries). It also adds
/usr/lib32 to /etc/ld.so.conf.
To make ldd work, a separate ldd32 script can be installed. It would be
even nicer if we could apply the following change to the ldd script in
our core glibc package:
< RTLDLIST="/lib/ld-linux-x86-64.so.2"
> RTLDLIST="/lib/ld-linux-x86-64.so.2 /lib/ld-linux.so.2"
That will make ldd work for both 32 and 64 bit binaries.
PROGRESS
I have built enough packages to install flash by just running 'pacman
-Sy flashplugin' (some are already out of date though). I also built
libgl and intel-dri to make OpenGL work on my Intel chip, other dri
modules as well as the Nvidia/Ati versions of libGL.so are on my
imaginary TODO list.
I didn't build enough to try wine yet, and I was going to wait with this
posting until then, but I am not sure when I will get to it. So this is
it, the repository (in my public_html for now):
[multilib]
Server = http://dev.archlinux.org/~thomas/multilib
I want to hear opinions about the idea and packages. Just try it by
running pacman -Sy flashplugin. I didn't upload any PKGBUILDs yet, I
want to clean them up first and see if and in what way the makepkg
patches are accepted upstream. I can upload some examples though.
SOME RANDOM DETAILS / TWEAKS:
- pango and gtk2:
Both pango and gtk2 install configuration files in /etc/ that contain
paths to plugins. For the 32 bit packages, I had to change the hardcoded
paths in the libraries and create separate configuration files for the
32 bit plugins. I also had to install 32 bit versions of the tools that
generate these configuration files.
- nspluginwrapper:
nspluginwrapper is split into two packages: The nspluginviewer package
contains only the 32 bit binaries and is built on a 32 bit system. The
nspluginwrapper package contains the 64 bit binaries and is built on a
64 bit system.
In order to properly install flash, nspluginwrapper has to create a
separate file that contains the location of the real plugin. I had to
patch nspluginwrapper so it is possible to manually specify the
directory it puts the file in (/usr/lib/mozilla/plugins by default, but
I needed ${startdir}/pkg/usr/lib/mozilla/plugins). The flash package is
built on 64 bit, due to the lack of the npconfig program on the 32 bit
system.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20080708/b5631b4e/attachment.pgp>
More information about the arch-dev-public
mailing list