Etwas OT: Cross-Compilierungsumgebung x86_64 Devel Host, i586 Target
Hallo, Ich bin auf der Suche nach Informationen wie man so etwas sauber hinbekommt, und zwar in der Hinsicht, dass diese Cross-Devel-Umgebung aehnlich dem ELDK (von DENX, wer das kennt) immer stabil bleibt, egal ob man auf dem Host Updates installiert oder nicht. Und nun entschuldige ich mich schon mal im Voraus fuer die recht lange Mail, ab hier braucht ja nur weiterlesen wen das Thema interessiert. :) Unser Target ist ein Atoemchen (Z510-Z530), Compilieren des Kernels, eigener Libs und Applkationen inklusive erstellen von RPMs sind mit den 32bit-Paketen von OS11.2 kein Problem, und das Zeugs laeuft sogar. Allerdings passiert das natuerlich immer mit den aktuell auf dem Host-System installierten 32bit-(devel-)Paketen von openSUSE (momentan 11.2). Hat jemand Informationen oder Ideen dazu, werden wohl Links sein, wie man das unter openSUSE elegant loesen koennte immer diesselben Includes, Libs, Binutils, usw. zu nutzen egal was das System drumherum so macht? Das Target ist ein Produkt auf dem OS11.2 (oder hoeher) i586 installiert ist und soll natuerlich immer "gleich" uebersetzt werden. - Wie gehabt nur per zypper/locks und RPM Spec Requires und BuildRequires mit exakten Versionen abdichten? - Cross-Pakete (z.B. cross-i386-binutils)???? Werde wir in unserem Fall wohl kaum brauchen? - gcc/binutils sysroot? - Includes+Libs manuell kopieren? - Manuell eigenen Tree erstellen, Devel-RPMs falls moeglich mit anderem Prefix/Root per rpm installieren, evt. andere, eigene RPM-Datenbank nutzen (wie z.B. auch das ELDK)? - Notloesung VirtualBox oder andere VM? Etwas laestig, etwas lahmer und unschoen. Vieles doppelt, z.B. Einstellungen, Emacs, usw. - Eigenen Build Server hochziehen? Ist das nicht etwas viel Aufwand fuer nur vier, fuenf Softies? Nur fuer Final Builds. - .. ? Ich stehe gerade noch ein wenig wie der Ochs' vor'm Berg wie ich das Problem angehen soll, obwohl ich selbst schon Cross-Compiler (den gcc fuer den 68332) angepasst habe und z.B. seit jahren mit den ELDKs arbeite. Fuer einen Schubs in die richtige Richtung waere ich sehr dankbar, Fahrt aufholen bekomme ich wenn die Richtung grob stimmt vermutlich selbst wieder hin. Roman -- Roman Fietze Telemotive AG Büro Mühlhausen Breitwiesen 73347 Mühlhausen Tel.: +49(0)7335/18493-45 http://www.telemotive.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Roman, On Tue, 23 Mar 2010, 11:01:20 +0100, Roman Fietze wrote:
Hallo,
Ich bin auf der Suche nach Informationen wie man so etwas sauber hinbekommt, und zwar in der Hinsicht, dass diese Cross-Devel-Umgebung aehnlich dem ELDK (von DENX, wer das kennt) immer stabil bleibt, egal ob man auf dem Host Updates installiert oder nicht.
Das schreit nach der Nutzung einer "chroot" Umgebung ala "build.rpm". Installier' dir mal das entsprechende Paket, und dann kannst du problemlos auch auf einem x86_64 System jederzeit Pakete fuer ein i586 System bauen, unabhaengig davon, welche Updates du heute, morgen, ... gerade auf dem Host installiert hast. : Bauen auf einem x86_64 System fuer ein x86_64 System (openSUSE 11.1): env BUILD_RPM_BUILD_STAGE="-ba" BUILD_DIST=11.1-x86_64 build --rpms `pwd`/RPMS --arch x86_64 --root `pwd`/root-`uname -i` paket.spec : Bauen auf einem x86_64 System fuer ein i586 System (openSUSE 11.1): linux32 env BUILD_RPM_BUILD_STAGE="-ba" BUILD_DIST=11.1-i586 build --rpms `pwd`/RPMS --arch i586 --root `pwd`/root-`linux32 uname -i` paket.spec Hier liegen in `pwd`/RPMS symbolic Links auf die Pakete, gegen die du bauen willst (also z.B. von dem 11.1 ISO Image). Das ist wesentlich sauberer, als eine vollstaendige Cross-Umgebung zu pflegen...
Und nun entschuldige ich mich schon mal im Voraus fuer die recht lange Mail, ab hier braucht ja nur weiterlesen wen das Thema interessiert. :)
HTH, cheers. l8er manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Tue, 23 Mar 2010 13:36:25 +0100, Manfred Hollstein
Das schreit nach der Nutzung einer "chroot" Umgebung ala "build.rpm".
Oder "osc build", das kann das gleiche und organisiert sich alles übers Netz :) Philipp -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, On Tuesday 23 March 2010 23:46:56 Philipp Thomas wrote:
Oder "osc build", das kann das gleiche und organisiert sich alles übers Netz
Ich arbeite regelmaessig mit dem Build System und osc. Sehe ich das falsch, oder hat das nicht den Nachteil, dass ich immer nur aus kompletten tars (plus SPECs und Patches) bauen kann? Das ist/waere fuer eine Entwicklung ziemlich unbrauchbar, speziell im Vergleich zu einer echten Cross Toolchain wie z.B. ELDK oder anderen die mit crostool gebaut wurden. Roman -- Roman Fietze Telemotive AG Büro Mühlhausen Breitwiesen 73347 Mühlhausen Tel.: +49(0)7335/18493-45 http://www.telemotive.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Moin, On Tue, 06 Apr 2010, 10:26:27 +0200, Roman Fietze wrote:
Hallo,
On Tuesday 23 March 2010 23:46:56 Philipp Thomas wrote:
Oder "osc build", das kann das gleiche und organisiert sich alles übers Netz
Ich arbeite regelmaessig mit dem Build System und osc. Sehe ich das falsch, oder hat das nicht den Nachteil, dass ich immer nur aus kompletten tars (plus SPECs und Patches) bauen kann?
Stimmt - prinzipiell auch fuer das lokale Bauen mit build.rpm. Bei Letzterem hast du aber auch die Moeglichkeit, die einmal aufgebaute "chroot" Umgebung liegen zu lassen, um dann jederzeit mittels chroot /path/to/build-root/where/are/my/sources wie in einem Zielsystem mit den korrekten Tools und Libraries zu arbeiten.
Das ist/waere fuer eine Entwicklung ziemlich unbrauchbar, speziell im Vergleich zu einer echten Cross Toolchain wie z.B. ELDK oder anderen die mit crostool gebaut wurden.
Je nachdem, was man gewohnt ist, kann man das Eine oder das Andere bevorzugen; solange aber nicht echte Architekturunterschiede im Spiel sind, die eine komplett separate Cross Toolchain erfordert, finde ich die "chroot" Variante durchaus gangbar!
Roman
HTH, cheers. l8er manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, On Tuesday 23 March 2010 13:36:25 Manfred Hollstein wrote:
Das schreit nach der Nutzung einer "chroot" Umgebung ala "build.rpm".
Etwas mit Kanonen nach Spatzen geschossen. Ich habe mir build mal angeschaut. Im Vergleich zu einer Cross Toolchain extrem aufwendig (kommt von aufwenden und nicht von Wand!!!!!). Mein momentaner Loesungansatz ist "meine" Devel-Pakete per rpm2cpio in ein eigenes cross-root zu installieren, die passenden cross-binutils fuer den i586 zu installieren (z.B. den /opt/cross/i586-linux/bin/ld), die ENV-Variable COMPILER_PATH passend zu setzen und den gcc mit --sysroot zu aufzurufen. Der cross-binutils-ld kann im Gegensatz zum "normalen" ld "etwas" mit sysroot anfangen. Noch nicht ganz perfekt (Suchpfad fuer Libs), aber vielleicht wirds ja noch was ohne dass ich einen eigenen gcc bauen muss. Roman -- Roman Fietze Telemotive AG Büro Mühlhausen Breitwiesen 73347 Mühlhausen Tel.: +49(0)7335/18493-45 http://www.telemotive.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Die, 06 Apr 2010, Roman Fietze schrieb:
Mein momentaner Loesungansatz ist "meine" Devel-Pakete per rpm2cpio in ein eigenes cross-root zu installieren, die passenden cross-binutils fuer den i586 zu installieren (z.B. den /opt/cross/i586-linux/bin/ld), die ENV-Variable COMPILER_PATH passend zu setzen und den gcc mit "normalen" ld "etwas" mit sysroot anfangen.
Noch nicht ganz perfekt (Suchpfad fuer Libs), aber vielleicht wirds ja noch was ohne dass ich einen eigenen gcc bauen muss.
Aus meinem 'gcc-3.3.5.env', das ich bei Bedarf source: ==== #!/bin/sh GCCBASEDIR="/opt/gcc/3.3.5" export PATH="${GCCBASEDIR}/bin:$PATH" export LD_LIBRARY_PATH="${GCCBASEDIR}/lib:$LD_LIBRARY_PATH" export MANPATH="${GCCBASEDIR}/share/man:$MANPATH" export INFOPATH="${GCCBASEDIR}/share/info:$INFOPATH" export INFODIR="${GCCBASEDIR}/share/info:$INFODIR" # [..] # das folgende, weil da noch sonstige evtl. neuere Header liegen # die statt denen in /usr/local und /usr verwendet werden sollen CFLAGS="${CFLAGS} -I${GCCBASEDIR}/include" # [..], ok, über -rpath hier kann man streiten, ist aber # praktisch um die gebauten binaries einfach so aufrufen zu können LDFLAGS="$LDFLAGS -Wl,-rpath,${GCCBASEDIR}/lib" # [..] export CC="${GCCBASEDIR}/bin/gcc" export CXX="${GCCBASEDIR}/bin/g++" export GCC="$CC" export GXX="$CXX" unset GCCBASEDIR ==== HTH, -dnh -- Dann siehst du nämlich ganz genau, daß der Cursor blinkt, und er hat feuerrote tote Augen, mit denen er dich anstarrt und brüllt: ".. UND WENN DU DICH VERTIPPST, DANN FRESSE ICH DICH MITSAMT DEINEM MAUSZEIGER!!!!" [Ratti in suse-programming] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo David, On Tuesday 06 April 2010 11:48:24 David Haller wrote:
export PATH="${GCCBASEDIR}/bin:$PATH"
Hast du dir diesen gcc selbst gebaut? Aus dem SRPM oder mit crosstool?
# das folgende, weil da noch sonstige evtl. neuere Header liegen # die statt denen in /usr/local und /usr verwendet werden sollen CFLAGS="${CFLAGS} -I${GCCBASEDIR}/include"
Bei mir ist eher das Problem, dass ich defintiv zumindest eine zeitlang mit aelteren Headern und Libs uebersetzen muss um mein Produkt nicht ausversehen zu zerlegen, d.h. mein Build Root macht die Online-Updates nicht automatisch mit. Bei dir kann es jetzt aber passieren, dass ein Header der nicht unter ${GCCBASEDIR}/include liegt automatisch und faelschlicherweise von /usr/include geholt wird, wenn irgendjemanden diesen (neu) verwendet (Beispiel: "ploetzlich" nutzt jetzt jemand Boost oder die libz). Oder sehe ich das falsch? Roman -- Roman Fietze Telemotive AG Büro Mühlhausen Breitwiesen 73347 Mühlhausen Tel.: +49(0)7335/18493-45 http://www.telemotive.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Die, 06 Apr 2010, Roman Fietze schrieb:
On Tuesday 06 April 2010 11:48:24 David Haller wrote:
export PATH="${GCCBASEDIR}/bin:$PATH"
Hast du dir diesen gcc selbst gebaut? Aus dem SRPM oder mit crosstool?
Äh, das ist einfach ein neuerer gcc hier im alten System, kein cross-, kein chroot. Und selbstgebaut aus dem tarball mit --prefix=/opt/gcc/3.3.5 (kein RPM).
# das folgende, weil da noch sonstige evtl. neuere Header liegen # die statt denen in /usr/local und /usr verwendet werden sollen CFLAGS="${CFLAGS} -I${GCCBASEDIR}/include"
Bei mir ist eher das Problem, dass ich defintiv zumindest eine zeitlang mit aelteren Headern und Libs uebersetzen muss um mein Produkt nicht ausversehen zu zerlegen, d.h. mein Build Root macht die Online-Updates nicht automatisch mit.
Bei dir kann es jetzt aber passieren, dass ein Header der nicht unter ${GCCBASEDIR}/include liegt automatisch und faelschlicherweise von /usr/include geholt wird, wenn irgendjemanden diesen (neu) verwendet (Beispiel: "ploetzlich" nutzt jetzt jemand Boost oder die libz). Oder sehe ich das falsch?
Jo, bei mir entfällt das Problem halt. Wollte nur zeigen, mit welchen Variablen du hantieren kannst ... Auch im chroot, das du eben wohl wg. o.g. brauchst. -dnh -- If Windows is the solution, can we please have the problem back? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, On Tuesday 06 April 2010 17:14:48 David Haller wrote:
Und selbstgebaut aus dem tarball ...
Genau das habe ich jetzt auch gemacht. Falls das hier mal jemand beim Suchen finden sollte: - binutils bauen mit --with-sysroot=<crossroot> und passendem --prefix, den gold habe ich noch nicht getestet - benoetigte Libraries via rpm2cpio xxx | cpio -id nach <crossroot> installieren, Minimum zum Bauen des gcc ist erst mal glibc, glibc-32bit, glibc-devel, glibc-devel-32bit. - gcc bauen mit --prefix wie oben, --sysroot wie oben, -enable-languages "natuerlich" nur c,c++, -with-arch-32=i586, -enable-linux-futex Das war's schon. Weitere Libs kann man dann ohne weiteres wie oben nachinstallieren oder manuell updaten. Erste kleine Testbinaries laufen denn auch auf dem Atoemchen, ein ldd sieht ebenfalls gut aus, ein strace beim make zeigt mir, dass die Tools nur auf <crossroot> zugreifen (Headers und Libs). Roman -- Roman Fietze Telemotive AG Büro Mühlhausen Breitwiesen 73347 Mühlhausen Tel.: +49(0)7335/18493-45 http://www.telemotive.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Tue, April 6, 2010 10:31 am, Roman Fietze wrote:
angeschaut. Im Vergleich zu einer Cross Toolchain extrem aufwendig (kommt von aufwenden und nicht von Wand!!!!!).
Das hat nichts mit der Wand zu tun, sondern mit dem Aufwand, den man aufw[äe]nden muß. Früher war nur aufwendig richtig, seit der Rechtschreibreform sind aber beide Formen zulässig. Grüße, Christian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (5)
-
Christian Brabandt -
David Haller -
Manfred Hollstein -
Philipp Thomas -
Roman Fietze