multilib w Ac

[Jakub Bogusz]

Dla jedynej wspieranej w Ac konfiguracji (x86_64/x86) wydaje się
działać (w prostym przypadku):

$ cat hello.c
#include <stdio.h>

int main()
{
        printf("Hello world.\n");
        return 0;
}
$ gcc -o hello hello.c
$ gcc -m32 -o hello32 hello.c
$ file hello hello32
hello:   ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.6, dynamically linked (uses shared libs), not stripped
hello32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.6, dynamically linked (uses shared libs), not stripped
$ ./hello
Hello world.
$ ./hello32
Hello world.

I podobnie:

$ cat hello.cc
#include <iostream>

int main()
{
        std::cout << "Hello world." << std::endl;
}
$ g++ -o hello+ hello.cc
$ g++ -m32 -o hello+32 hello.cc
$ ldd hello+
        libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x0000002a9566c000)
        libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a9584a000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000002a959ce000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a95ad8000)
        /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)
$ ldd hello+32
        linux-gate.so.1 =>  (0xffffe000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x55597000)
        libm.so.6 => /lib/tls/libm.so.6 (0x55657000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x5567a000)
        libc.so.6 => /lib/tls/libc.so.6 (0x55682000)
        /lib/ld-linux.so.2 (0x55555000)

Chcemy takie gcc w Ac?

Wymagania to nowe (tzn. podwójne) llh (>= 2.6.10.0-3) oraz dwie wersje
glibc (glibc.{i686 lub athlon[1]} + glibc64.amd64) i glibc-devel[2].
[1] bezpieczniej i686, żeby nie wyszło coś w przypadku ia32e
[2] chyba rozumiem dlaczego RH ma wydzielone glibc-headers
z glibc-devel: dowiązania *.so itp. z x86 są potrzebne, ale nagłówki
mają być (tylko) z x86_64. rpm niby pozwala zainstalować obie wersje
nie zgłaszając konfliktu, ale pliki nagłówków zostają z ostatniej
zainstalowanej wersji. Przynajmniej tak jest z rpm-em z Ac.

Pojawił się jeszcze problem z chrpath, który w wersji x86_64 nie
obsługuje binarek ELF32 z x86 (zgłasza błąd - budowanie się nie
wykłada, ale RPATH zostaje).


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/