32bit Anwendung auf amd64

Ok, das dacht ich mir schon :-D Wäre ja möglich gewesen dass es eine elegantere Lösung gibt.
Frage 2 wäre damit noch offen.
 
Columbo und ich haben heute Morgen in IRC mal ein wenig gebastelt. Ein 32-Bit mplayer, ein gvim und ein paar Kleinigkeiten gingen. Allerdings gibt es dot noch einen Bug im dynamischen Linker, den ich erst einmal genauer anschauen will, bevor ich hier eine Anleitung tippe.
 
Moin,

die Anleitung (von Yamagi) werde ich noch nachreichen (die Arbeit brauchst du dir wirklich nicht machen). Es ist jedoch so, dass bisher nur wenige Ports laufen. Ich habe gestern versucht "devede" mit allen Abhängigkeiten zu übersetzen und zum Laufen zu bringen. Es kommen einige gtk-Fehler, die ich mir noch nicht genauer angesehen habe.

Zumindest "spumux" läuft ohne "core dumped", was jedoch nicht wirklich hilft, da ich selbst das Programm nicht aufrufe sondern devede. Leider kann man devede nicht sagen, wo die "Zusatzprogramme" liegen, sodass er immer die amd64-Programme nimmt. Die (evtl. mögliche) harte Variante, die Zusatzprogramme einfach zu löschen und die i386-Binarys in den PATH zu legen, wollte ich dann doch nicht gehen.

Vielleicht ist ja Kamikazes Ansatz erfolgreicher?
 
Columbo0815 schrieb:
Es kommen einige gtk-Fehler, die ich mir noch nicht genauer angesehen habe.
Zum Vergrößern anklicken....
Das Problem ist, dass das GTK auf dem Host in 64-Bit Version vorliegt. Wenn eine GTK-Anwendung gestartet wird, schaut es in ~/.gtkrc nach, welches Theme genutzt werden soll. In der Themedatei wiederum steht, welche Themeengine genutzt werden soll, diese liegt als 64-Bit Bibliotek vor und wird dynamisch in das 32-Bit Programm gelinkt. Das explodiert wunderbar. Ich weiß nicht, ob es ausreicht, eine 32-Bit Version der Themeengine zur Verfügung zu stellen (die sind unter /usr/ports/x11-themes zu finden) oder ob man da noch irgendwelchen Voodoo machen muss.
 
Der Jail-Ansatz ist auf jeden Fall vielversprechender. Ich werde hier mal heute Abend posten was ich so alles mit der Jail angestellt habe, damit sie lief.
 
So. Hier jetzt mal eine kurze Anleitung, wie man ein FreeBSD/i386 Binary auf FreeBSD/amd64 laufen lassen kann. Wer möchte kann es auf eigene Gefahr nachmachen, ich kann nicht wirklich viel dazu schreiben, weil ich selbst nicht ganz genau weiß, was gemacht wird.

Ich gehe davon aus, dass die Binarys vorhanden sind und in /mnt/bin32 liegen. Die benötigten libs liegen in /mnt/lib32. /mnt ist bei mir ein NFS-Mount, den ich nur benutze um die Binarys irgendwo Zwischenlagern zu können.

# ldconfig -32 ""
Zum Vergrößern anklicken....
Was mit einer Fehlermeldung bestätigt wird. Das ist so auch iO. Dieser Aufruf ist wohl wegen des von Yamagi erwähnten Bugs notwendig.
Dann
$ setenv LD_32_LIBRARY_PATH /mnt/lib32
Zum Vergrößern anklicken....
bzw
$ export LD_32_LIBRARY_PATH=/mnt/lib32
Zum Vergrößern anklicken....
Abhängig von der verwendeten Shell. In dem Terminal in dem ihr setenv oder export ausgeführt habt, startet ihr dann das binary. zB: /mnt/bin32/mc

Damit zB "devede" überhaupt einen Schritt weiter kommt, muss ich auch den PATH um /mnt/bin32 ergänzen.

Wie gesagt. Nur vereinzelte Ports laufen und genau die, die ich starten möchte versagen mit einem
Traceback (most recent call last):
File "/mnt/bin32/devede", line 25, in <module>
import gtk
File "/usr/local/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py", line 38, in <module>
import gobject as _gobject
File "/usr/local/lib/python2.5/site-packages/gtk-2.0/gobject/__init__.py", line 30, in <module>
from gobject.constants import *
File "/usr/local/lib/python2.5/site-packages/gtk-2.0/gobject/constants.py", line 22, in <module>
from _gobject import type_from_name
ImportError: /usr/local/lib/python2.5/site-packages/gtk-2.0/gobject/_gobject.so: unsupported file layout
Zum Vergrößern anklicken....
 
So. Ein anderer Ansatz ist ja ein i386-Jail. Nachfolgend wieder eine kurze Anleitung, was ich bislang getan habe und was bisher läuft:

cd /usr/src
make TARGET_ARCH=i386 TARGET=i386 buildworld
Zum Vergrößern anklicken....
danach
mkdir -p /foo/bar/i386
make TARGET_ARCH=i386 TARGET=i386 DESTDIR=/foo/bar/i386 installworld
Zum Vergrößern anklicken....
und dann ein
make TARGET_ARCH=i386 TARGET=i386 DESTDIR=/foo/bar/i386 distribution
Zum Vergrößern anklicken....
Der/Die/Das Jail ist soweit fertig. Damit ich das Jail bequem per "/etc/rc.d/jail start i386" starten kann (bzw. damit es später mal mit dem Boot gestartet wird), habe ich noch meine /etc/rc.conf wie folgt ergänzt:

jail_enable="YES" # Set to NO to disable starting of any jails
jail_list="i386" # Space separated list of names of jails
jail_i386_rootdir="/foo/bar/i386" # jail's root directory
jail_i386_hostname="www.example.org" # jail's hostname
jail_i386_ip="192.168.1.50" # jail's IP address
jail_i386_devfs_enable="YES" # mount devfs in the jail
Zum Vergrößern anklicken....

Kamikaze hat mir gesagt, dass ich noch ein "mount_nullfs /usr/lib32 /foo/bar/i386/usr/lib" starten muss. Ebenso musste ich ld-elf.so.1 und ld-elf32.so.1 von /libexec in das Jail-/libexec kopieren bevor ich das Jail ohne Fehler starten konnte. /usr/lib32 aus dem Jail musste ich noch nach /usr/lib aus dem Jail linken.

So. Jail startet. bislang habe ich noch keinen Zugriff auf das Netzwerk. Der sshd kann auch nicht gestartet werden.

Im Jail arbeiten kann ich mit "jail /foo/bar/i386/ i386 192.168.1.50 /bin/tcsh.
 
Kleine Ergänzung hier, lieber auf den Symlink verzichten und /usr/lib32 nach /foo/bar/i386/usr/lib32 mounten damit man nichts verdeckt. Leider hat die 32-Bit Compat einen Linker-Bug der ein Weiterkommen ab einem gewissen Punkt verhindert.

Um Ports in der Jail zu bauen sollte man in die make.conf folgendes eintragen:
Code: 
ARCH=		i386
TARGET=		i386
LDEMULATION=	elf_i386_fbsd
GNUTARGET=	elf32-i386-freebsd
 
Nachtrag: Damit das Netzwerk funktioniert, muss man der "echten" Netzwerkkarte eine weitere IP zuweisen:

ifconfig em0 192.168.1.50 netmask 255.255.255.255 (em0 evtl. ersetzen). Weiterhin muss man noch den nameserver in /etc/resolv.conf (in der Jail) eintragen.

Netzwerk geht soweit. jetzt werden demnächst ports gebaut.
 
So. portinstall konnte ich fehlerfrei installieren. Aktuell hänge ich an mc, der perl benötigt.

Hier kommt die Fehlermeldung:
/libexec/ld-elf.so.1: Shared object "libperl.so" not found, required by "perl"
*** Error code 1 (ignored)
*** Error code 1 (ignored)
LD_LIBRARY_PATH=/usr/ports/lang/perl5.8/work/perl-5.8.8 ./miniperl -Ilib configpm --heavy=lib/Config_heavy.pl lib/Config.pm
/libexec/ld-elf.so.1: Shared object "libperl.so" not found, required by "miniperl"
*** Error code 1

Stop in /usr/ports/lang/perl5.8/work/perl-5.8.8.
*** Error code 1

Stop in /usr/ports/lang/perl5.8.
** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portinstall.34231.0 env make
** Fix the problem and try again.
** Listing the failed packages (-:ignored / *:skipped / !:failed)
! lang/perl5.8 (unknown build error)
Zum Vergrößern anklicken....
 
Geil! Vielleicht habe ich nächstes Wochenende etwas Zeit um das auch mal auszuprobieren und eventuell ein Script zu schreiben, das den Vorgang automatisiert.
Damit hat man jetzt jedenfalls viele neue Möglichkeiten! Sollte auf jeden Fall noch ins Wiki das ganze! Wenn man jetzt verrückt genug ist kann man jetzt noch den Patch einspielen um X in einer Jail laufen zu lassen und schon kann man das ganze Grafische System schön oldschool auf i386 betreiben, jedoch mit dem nachteil dass die Jail nichtmehr sicher ist.
 
Hmm, so lange der Linker-Bug nicht behoben ist, der wahrscheinlich auch für das Problem mit Perl verantwortlich ist, wird es auch nichts mit einer richtig funktionierend i386 Jail. Letzte Woche hat das Team mal sein i386-compat Knowhow zusammengeschmissen. Dabei kam eine Menge zusammen, was sich ja auch ein wenig an Columbo's Fortschritten zeigt, dem wir im IRC ein paar Hinweise geliefert haben.

Jedoch hat Yamagi einen Bug im Linker gefunden, der einen Erfolg verhindert. Ich denke Yamagi hat hier auf jeden Fall das tiefgehendste KnowHow im Team. Also sollte ich den das besser erklären lassen, wenn er bereit ist dazu nähere Angaben zu machen.

Jedenfalls kann ich euch versichern, es wird einen Wiki-Artikel geben sobald wir oder das FreeBSD-Projekt alle Probleme lösen können. Ich denke ich werde dann auch eine englische Kopie ins FreeBSD-Wiki stellen.
 
Es ist ganz einfach. In aktueller Version (hier FreeBSD 7.0, aber auch in 7-STABLE bestätigt), findet der Linker indirekt referenzierte Biblioteken nicht. Ein Beispiel: Die Bliblioteken A, B und C sind im Pfad des Linkers. Programm "Test" referenziert Bibliotek A und B, Bibliotek B wiederum C. Während A und B korrekt gelinkt werden, sagt er zu C einfach "not found". Daher funktionieren einfache Programme ohne große Abhängigkeiten problemlos, komplexere hingegen nicht. Ich bin gerade dabei das ganze noch ein wenig mehr aufzudröseln, sodass ich einen guten Hinweis an die Mailinglisten senden kann.
 
Kamikaze schrieb:
Letzte Woche hat das Team mal sein i386-compat Knowhow zusammengeschmissen. Dabei kam eine Menge zusammen, was sich ja auch ein wenig an Columbo's Fortschritten zeigt, dem wir im IRC ein paar Hinweise geliefert haben.
Zum Vergrößern anklicken....
Auch wenn das nicht deine Intension war, möchte ich an dieser Stelle ausdrücklich darauf hinweisen, dass nicht ich mir die ganze Arbeit mache sondern diese tatsächlich von anderen erledigt wird. Insbesondere Yamagi und Kamikaze liefern mir sehr sehr viele Hinweise. Aber auch andere sind (im IRC) sehr hilfreich (alle aufzuzählen ist fast unmöglich). Ich gebe das hier nur wieder um es auch anderen zu ermögliches so etwas laufen zu lassen. :)

Also: Danke mal an alle Helfer. Vielleicht ist das Ergebnis dieses Threads tatsächlich mal ein Wiki-Artikel, der zeigt wie man i386-Programme auf einem amd64 System laufen lassen kann (zumindest so lange, bis die Programme selbst auf amd64 funktionieren).

Gruß
 
Ok, danke für den Hinweis Yamagi. Das klingt ja wie ein kleines Versäumnis des entsprechenden Entwicklers, also nichts all zu schwerwiegendes. Wie gesagt. Hätte ich Zeit.. aber das ist ja vorerstnicht der Fall.. bin grade am Umziehen. Vielleicht schau ich mir das dann nächstes WE auch mal an :D :D
 
In -current könnte der Bug gefixt sein, zumindest wurde eine Korrektur eingefügt. Ich konnte es allerdings noch nicht testen.
 
Nun, das sind doch gute Nachrichten. Schade, dass ich am Wochenende keine Zeit habe das ganze auszuprobieren.
 
Moin, wollte mal nachfragen ob sich das vielleicht schon jemand ansehen konnte.. Ich habe leider keine Möglichkeit ein -current laufen zu lassen um das zu probieren.

Gruß
 
Der Patch ist inzwischen in 7-STABLE gelandet und wird damit noch Teil von 7.1 werden. Getestet habe ich es allerdings noch nicht :/
 
Nun, dann kann mich nichts mehr halten. Ich probiere das jetzt.

---update---

In meiner Jail hat sich nichts geändert:
Code: 
 `sh  cflags "optimize='-O2 -fno-strict-aliasing -pipe -march=prescott'" opmini.o` -DPIC -fPIC -DPERL_EXTERNAL_GLOB opmini.c
	  CCCMD =  cc -DPERL_CORE -c -DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.8/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -O2 -fno-strict-aliasing -pipe -march=prescott  -Wall
LD_LIBRARY_PATH=/usr/obj/usr/ports/lang/perl5.8/work/perl-5.8.8 cc -Wl,-E -L/usr/local/lib -o miniperl  miniperlmain.o opmini.o libperl.so -lm -lcrypt -lutil
LD_LIBRARY_PATH=/usr/obj/usr/ports/lang/perl5.8/work/perl-5.8.8 ./miniperl -w -Ilib -MExporter -e '<?>' || make minitest
/libexec/ld-elf.so.1: Shared object "libperl.so" not found, required by "miniperl"
"makefile", line 952: Need an operator
make: fatal errors encountered -- cannot continue
*** Error code 1

Stop in /usr/obj/usr/ports/lang/perl5.8/work/perl-5.8.8.
*** Error code 1

Stop in /usr/ports/lang/perl5.8.
 
Zuletzt bearbeitet:
Dein Kernel ist neuer als von gestern Mittag? (Echt geniale Ausdrucksweise, ich weiß ^^). Dann ist es schlecht.
 
Ja, ich habe erst nach deinem Post die Sourcen gezogen. Ich habe auch die Jail neu gebaut. Die libperl.so die er nicht findet ist vorhanden.
 
Hm, das heißt dann vermutlich, dass die Änderung gar nichts mit diesem Fehler zu tun hatte, oder? Vermutlich wird das ganze dann in -current auch noch nicht funktionieren.

Schade, das heißt dann wohl "weiter warten".
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben