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.