32bit Anwendung auf amd64

Columbo0815

Kaffeemann
Teammitglied
Moin,

Grund für diesen Thread: Ich habe verschiedene Ports, die entweder gar nicht oder sehr bescheiden auf amd64 laufen. Zuletzt: spumux core dumped. Ich habe nun gelesen, dass es möglich sein soll 32bit Anwendungen auf einem 64bit-System laufen zu lassen.

Es ist gegeben: FreeBSD 7.0/amd64 [7.0-RELEASE-p4]

Was ich weiß: Gar nichts, weil ich keinerlei Informationen darüber gefunden habe, wie man mein "Vorhaben" umsetzen kann. Weder im Handbuch noch auf irgendwelchen Internetseiten. manpages hätte ich zugerne gelesen, wenn ich wüsste welche. Ich weiß nur: Es soll möglich sein. Entweder mit einem "32-bit-chroot" oder ohne chroot mit /usr/lib32.

Was habe ich bereits getan: Viel gesucht, nichts gefunden. Weiterhin habe ich /usr/lib32/install.sh ausgeführt ohne zu verstehen was es tut. Nun habe ich in diesem Verzeichnis viele viele Libs (?) liegen. Danach habe ich "ldconfig -32 /usr/lib32" ausgeführt.

Was ich gerne hätte: Da verschiedene Ports nicht auf amd64 laufen würde ich diese gerne für i386 kompilieren und auf meinem System ausführen. Idealerweise auch unter X. Schön wäre es, wenn ich explizit beim installieren sagen könnte "ey, jetzt 32bit". Sowas wie "portinstall -32 /usr/ports/multimedia/dvdauthor".

Zur Not - wenn das Selbstübersetzen für i386 zu umständlich ist - nehme ich auch Binarys.

Was ich noch anmerken wollte: Ich habe gelesen, dass ich in /usr/src "make build32" und "make install32" ausführen soll. Das habe ich noch nicht getan.

Fehlen Angaben? Sagt mir welche, ich liefere sie.

Gruß
 
Glaub' mir das kannst du vergessen. Irgend etwas stimmt da mit dem Linker nicht. Ich habe mich damit intensiv beschäftigt und da muss man definitiv an den Code.
 
Wie Kamikaze schreibt, ist es fast unmöglich unter einem FreeBSD es hinzubekommen. Unter Linux gehts theoretisch, aber so prall ist es auch nicht. Das einzige System, wo dies wirklich klappt ist Windows mit Hilfe von WOW64.

Was funktioniert, ist die "Lösung für arme Männer". Man nehme ganz einfach ein statisch gelinktes Programm. Alternativ nutze man eine Linuxversion des Programms im Linuxulator.
 
Moin,

Danke schonmal für die Infos..

Das erklärt, warum ich wohl nichts "offizielles" hierzu gefunden habe. Ich vermute mal, dass ich weder "statisch gelinkte 32bit Versionen" noch "Linuxversionen" des Programmes selbst übersetzen kann und wohl auf Binarys angewiesen bin? Ok, zweiteres könnte wohl funktionieren, habe da mal irgendwas mit "Crosscompiling" (??) gelesen. Aber das ist wohl wesentlich mehr gefrickel als Binarys.

Meintest du mit Linuxversion eine 32 oder 64bit Version des Programmes?

Ich werde jetzt mal /usr/ports/emulators/linux_base-f8 testen. Wenn ich mich richtig erinnere werden auch die Programme nach /compat installiert, womit ich leben könnte. :)

Gruß
 
Das 32-Bit Linux-geraffel funktioniert problemlos unter FreeBSD/amd64. Dynamisch gelinkte FreeBSD/i386 Binaries machen den Ärger.

Falls du dich auf den Crosscompiling-Artikel im Wiki beziehst, der bezieht sich nur auf's Basissystem.
 
Ok.. Ich denke ich werde hier meine Fortschritte/Rückschläge posten. Wird evtl. noch andere Leute interessieren.

linux_base-f8 lässt sich nicht bauen. Er meint, dass linux-2.4.2 nicht unterstützt wird. Nun gut. linux_base-fc4 baut und wird auch im Handbuch beschrieben.

Jetzt habe ich mit "rpm -i --ignoreos --root /compat/linux --dbpath /var/lib/rpm package" versucht ein rpm von dvdauthor zu installieren. Zuerst meckert er, dass /var/lib/rpm/packages nicht existiert. Also habe ich /usr/compat/linux/var/lib/rpm/packages angelegt und das geliche danach noch einmal versucht das rpm zu installieren.

Aktuell - weiter habe ich noch nichts unternommen, werde ich demnächst tun - mault er folgendes:

/bin/sh wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libc.so.6 wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libc.so.6(GLIBC_2.0) wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libc.so.6(GLIBC_2.1) wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libc.so.6(GLIBC_2.1.1) wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libc.so.6(GLIBC_2.2) wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libc.so.6(GLIBC_2.3) wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libc.so.6(GLIBC_2.3.4) wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libc.so.6(GLIBC_2.4) wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libdl.so.2 wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libdvdread.so.3 wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libfreetype.so.6 wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libm.so.6 wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libm.so.6(GLIBC_2.0) wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libpng12.so.0 wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libpng12.so.0(PNG12_0) wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libxml2.so.2 wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
libz.so.1 wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht
rtld(GNU_HASH) wird von dvdauthor-0.6.11-1.2.el5.rf gebraucht

Juhu.. :ugly:
 
Ok.. Ich denke ich werde hier meine Fortschritte/Rückschläge posten. Wird evtl. noch andere Leute interessieren.

linux_base-f8 lässt sich nicht bauen. Er meint, dass linux-2.4.2 nicht unterstützt wird. Nun gut. linux_base-fc4 baut und wird auch im Handbuch beschrieben.

Hast du compat.linux.osrelease=2.6.16 gesetzt?
 
Yamagi... ich muss dir wiedersprechen. Das Geraffel ist auf Ubuntu, Debian, und Co scheiße aber auf RHEL respektive CentOS läuft das wie ich finde sehr gut.
 
Hast du compat.linux.osrelease=2.6.16 gesetzt?
Nachdem ich das jetzt gesetzt habe, funktioniert es. Ich hatte mit so etwas gerechnet. Aber im Portsverzeichnis ist keine Information darüber zu finden, weshalb ich zuerst den fc4 installiert habe.

Nun läuft compat_linux-f8. Danke :)

Um die fehlenden Libs kümmere ich mich jetzt mal nach und nach (bzw. ich versuche es) :)

Gruß
 
fc4 ist der Standard-Linuxport und braucht Kernel-Version 2.4.x.
In /usr/ports/UPDATING steht, dass man für die neueren Fedora-Versionen die Kernel-Version hochsetzen muss.
 
Yamagi... ich muss dir wiedersprechen. Das Geraffel ist auf Ubuntu, Debian, und Co scheiße aber auf RHEL respektive CentOS läuft das wie ich finde sehr gut.

unter gentoo läuft das auch gut und transparent. falls irgendein paket 32er libs braucht, rennt portage los und holt die entsprechenden emul-pakete, baut und installiert sie.
 
Meine eigenen Gentoo Erfahrungen liegen noch in der prä-64Bit Ära. Leider wurde es in dieser Zeit etwas bunt und komisch, da es im Projekt damals krieselte, ansonsten hätte ich es wohl damals noch länger genutzt.
 
Also, ich muss nun leider eingestehen, dass ich mich da oben ein wenig zu weit aus dem Fenster gelehnt habe. Ich meine nicht Linux, dazu kann ich leider nur sagen "dann wird es unter Linux inzwischen wohl gehen", da mir einfach eine aktuelle Version einer Distribution fehlt, um da einen eigenen Testlauf zu machen. Ich glaube euch einfach mal. :)
Nein, ich meine FreeBSD. Meine letzten großen Versuche ein i386 Programm unter einem FreeBSD/amd64 zum Laufen zu bringen, waren seinerzeit unter einem 6.2. Ich ging davon aus, dass sich nicht viel geändert hätte, aber dem ist nicht so. Ich habe hier eben unter einem FreeBSD/amd64 7.0-p4 einige Tests gemacht. Es ist problemlos möglich FreeBSD/i386 Programme zu starten, wenn man die benötigten dynamischen Biblioteken zur Verfügung stellt. Ein dynamisch gelinkter nvi und ein dynamisch gelinktes unrar starten und funktionieren ohne jedes Problem. Lediglich ldd(1) kommt mit den ELF-Images nicht klar, aber das ist ein bekanntes Problem und sollte in 7-STABLE behoben sein.
Also, kurzes und vielleicht zu frühes Fazit: Dynamisch gelinkte i386-Programme funktionieren unter einem FreeBSD/amd64 7.0, wenn man die Biblioteken zur Verfügung stellt. Damit rollt der Stein nun zu den Ports ;)
 
Noch mal ein wenig genauer. "beast" ist eine FreeBSD/i386 Installation
Code:
yamagi@beast:ttyp0 ...local/bin: uname -mr                           [20:01:00]
7.0-RELEASE-p4 i386
und "lame" ist aus den Ports installiert und dynamisch gelinkt:
Code:
yamagi@beast:ttyp0 ...local/bin: file lame                           [20:01:04]
lame: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), stripped
0.000u 0.003s 0:00.07 0.0%	0+0k 4+0io 16pf+0w
yamagi@beast:ttyp0 ...local/bin: ldd lame                            [20:02:33]
lame:
	libncurses.so.6 => /lib/libncurses.so.6 (0x280be000)
	libm.so.4 => /lib/libm.so.4 (0x28102000)
	libc.so.6 => /lib/libc.so.6 (0x28118000)
0.000u 0.002s 0:00.00 0.0%	0+0k 0+0io 0pf+0w

Nun haben wir "screw", meine FreeBSD/amd64 Box:
Code:
yamagi@screw:ttyp0 ~/temp: uname -mr                                 [19:59:15]
7.0-RELEASE-p4 amd64
auf welche wir den "lame" kopieren:
Code:
yamagi@screw:ttyp0 ~/temp: scp beast.home.yamagi.org:/usr/local/bin/lame .
Password:
lame                                          100%  268KB 268.3KB/s   00:00
Wie bereits gesagt, versagt ldd(1) nun:
Code:
yamagi@screw:ttyp0 ~/temp: file lame                                 [20:04:34]
lame: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), stripped
0.000u 0.003s 0:00.04 0.0%	0+0k 4+0io 14pf+0w
yamagi@screw:ttyp0 ~/temp: ldd lame                                  [20:05:22]
ldd: lame: can't read program header
ldd: lame: not a dynamic executable
aber wir können lame problemlos starten:
Code:
yamagi@screw:ttyp0 ~/temp: ./lame                                    [20:05:25]
LAME 32bits version 3.97 (http://www.mp3dev.org/)

usage: ./lame [options] <infile> [outfile]

    <infile> and/or <outfile> can be "-", which means stdin/stdout.

Try:
     "./lame --help"           for general usage information
 or:
     "./lame --preset help"    for information on suggested predefined settings
 or:
     "./lame --longhelp"
  or "./lame -?"              for a complete options list

0.000u 0.001s 0:00.00 0.0%	0+0k 0+0io 0pf+0w

Funktioniert also durchaus. Es scheitert mit komplexeren Ports nur an den Biblioteken, welche nicht zur Verfügung gestellt werden. Der nächste Schritt wäre nun ein weiterer Versuch ein i386-Jail unter einem amd64 zum Laufen zu bringen, aber das muss ein paar Tage bis Wochen warten.
 
Noch mal ein wenig genauer. "beast" ist eine FreeBSD/i386 Installation
Verstehe ich das richtig? Du hast auf einer FreeBSD/i386-Installation einen Port gebaut und den samt Bibliotheken auf einer amd64 Installation zum Laufen gebracht? Wäre für mich auch ein Weg, zumindest dann wenn FreeBSD in qemu gescheit läuft. Werde ich dann wohl mal installieren.
Funktioniert also durchaus. Es scheitert mit komplexeren Ports nur an den Biblioteken, welche nicht zur Verfügung gestellt werden.
Was sind komplexere Ports? Sachen wie kde will ich natürlich nicht ;) Aber Dinge wie dvdauthor, grun, avidemux2 oder ähnliches sind ports, die ich schon vermisse. Evtl. liese sich damit ja auch xosview bauen? :)

Der nächste Schritt wäre nun ein weiterer Versuch ein i386-Jail unter einem amd64 zum Laufen zu bringen, aber das muss ein paar Tage bis Wochen warten.
Was auch immer das heißt oder bringt, es hört sich nach bastelei an, was ich eigentlich nicht (mehr) wollte. :)

Gruß
 
Verstehe ich das richtig? Du hast auf einer FreeBSD/i386-Installation einen Port gebaut und den samt Bibliotheken auf einer amd64 Installation zum Laufen gebracht?
Genau. Ich habe den Port gebaut und auf meine amd64 Maschine kopiert. Biblioteken waren nicht nötig, da Lame lediglich auf welchen aus dem Basissystem basiert und nicht auf anderen Ports. Die hat man eh schon.

Was sind komplexere Ports?
Alles, was mehr als eine handvoll Biblioteken benötigt. Avidemux benötigt da z.B. schon ne verdammt große Menge. Hier würde ich auf jemanden mit Ports-Foo verweisen, der es genauer erklärt, aber grundsätzlich müsste dies möglich sein: Ändere das Prefix der Ports, z.B. in /usr/local32 und installiere aus einer i386-Installation dorthin. Anschließend kopiere /usr/local32 auf die amd64-Installation, biege die Pfade des 32-Bit Linkers entsprechend hin und es müsste / sollte gehen. In der Theorie müsste mit dieser Methode alles laufen, was nicht im Kernel hängt (der nVidia-Blob wäre sowas). Praktisch weiß ich natürlich nicht..
 
Das mit den Ports habe ich alles versucht, ich habe ARCH und TARGET gesetzt. Aufrufe um Parameter ergänzt und dem ganzen sogar ein gefälchtes uname untergejubelt damit es i386 statt amd64 ausspuckt. Einige Ports produzieren trotzdem nur amd64 Binaries und damit ist die Chose im Eimer.
 
Ich habe heute Morgen meine alten Experimente wieder ausgepackt und ich bin ein ganzes Stück weitergekommen. Die Ports bauen jetzt i386 Binaries, allerdings Segfaultet die gmake Binary, was ich durch setzen von GMAKE=/usr/local/bin/gmake umgehen kann. Leider bekomme ich auch cdparanoia nicht gebaut. Um den gettext Port zu bauen musste ich 2 Zeilen Code auskommentieren in denen malloc neu definiert wird und ich musst einen Info-File aus /usr/local kopieren um den Port zu installieren.

Im Gegensatz zu gmake, das ohne Klagen baut, funktionieren die gettext Binaries allerdings. Die m4 Binaries segfaulten auch. Ich werde mich wohl wieder auf eine Jail-Lösung konzentrieren müssen.
 
Also, in meiner Jail baut so ziemlich alles. Nur die Anwendungen die ich eigentlich haben will nicht (mencoder und wine). Da scheitert der Linker obwohl Libraries definitv vorhanden sind und auch die Pfade stimmen.
 
Hört sich interessant an, Leute! Weiter so :D

Hab zwar noch kein 64Bit, aber in einem Jahr bestimmt und dann wäre es schon super wine zu haben!

Also, in meiner Jail baut so ziemlich alles. Nur die Anwendungen die ich eigentlich haben will nicht (mencoder und wine). Da scheitert der Linker obwohl Libraries definitv vorhanden sind und auch die Pfade stimmen.

Warum brauchst du mencoder-32Bit?
 
Kamikaze könntest du bitte erläutern wie du die i386 Jail gebaut hast?
Klingt soweit ja sehr interessant.

Du willst also wine in der i386 Jail bauen. Woran genau scheitert es denn? Hat ja nicht viele deps aber libXpm die du benörigst hat ja wiederum X11 als dependency.
 
Man baut einfach ein i386 FreeBSD und installiert das mit DESTDIR=/jail/location und mergemaster -D/jail/location.

Warum brauchst du mencoder-32Bit?
Weil XviD encoding unter amd64 unglaublich lahm ist. Mein amd64 Core2 Duo mit 2.4 GHz ist kaum schneller als mein alter i386 Pentium-m mit 1.3GHz.
 
Zurück
Oben