[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