Multilib mechanism on a x86_64 arch?


What is the multilib mechanism on Gobolinux to get lib64 and lib32 for a software ? Maybe there is something about that, but I did not find any documentation on this subject.

I will take Wine as example, I decided to give it a first try with the last version (6.16) of Wine, the compilation failure does not surprise me, I expected it

checking whether gcc -m32 works... no
configure: error: Cannot build a 32-bit program, you need to install 32-bit development libraries.
PrepareProgram: configure failed.

and I must admit I have no clues on how to proceed on Gobo to build softwares with lib64 and lib32 compatibility on a x86_64 arch.

1 Like

There’s no support for multilib on Gobo. What I have done in the past was to simply resort to a chroot() environment. An alternative I used for a while (but which is a lot of work) is to unpack 32-bit packages from other distros (e.g., Glibc, CoreUtils, Bash, etc) or ancient 32-bit versions of Gobo under e.g., /Programs-i686, and then use Runner to create a Dependencies file that includes them all. Something like this:

$ cat /Programs-i686/MPlayer/<version>-i686/Resources/Dependencies
ALSA-Lib 1.0.29-i686
ATK 2.10.0-i686
Bzip2 1.0.6-i686
Cairo 1.12.16-i686
Expat 2.1.0-i686
Fontconfig 2.11.0-i686
FreeType 2.5.2-i686
GDK-Pixbuf 2.30.2-i686
Giflib 4.2.3-i686
GLib 2.47.6-i686
Glibc 2.18-i686
GTK+ 2.24.22-i686
HarfBuzz 0.9.27-i686

$ ls /Programs-i686/Bzip2

Then, prepare a union-mount of the 32-bit and 64-bit trees:

$ mkdir -p /tmp/workdir /tmp/programs_merged
$ mount -t overlay overlay -o lowerdir=/Programs,upperdir=/Programs-i686,workdir=/tmp/workdir /tmp/programs_merged
$ mount -o bind /tmp/programs_merged /Programs

Last, spawn the program with Runner:

$ Runner MPlayer/<version>-i686/bin/mplayer

This works fine for binary packages, but it won’t integrate nicely with Compile. In that case your best bet is to go with binary packages from other distros, I’m afraid.

That’s really not good news :frowning_face:

I started to study the methods which have been adopted in other distributions. Would there be a problem in a mechanism which would give the possibility of something like:

ls -l /usr/lib32/ -> /Programs/ALSA-Lib/
ls -l /System/Index/lib32/ -> /Programs/ALSA-Lib/

i don’t have enough view on Gobolinux right now to imagine if this could be an avenue to consider. Maybe there would be something smarter to build on Gobolinux in this case.

Have you perhaps already thought about this ?

1 Like

Frankly, I have not. We’ve basically ignored 32-bit apps and decided to resort to virtualization for those needing that.