Re: wie für 32bit über setzen?

Hallo,

Erstmal: dieses und ähnliche Themen gehören _eindeutig_ auf
opensuse-programming-de.

X-Mailed & F'up dahin.

Am Son, 16 Aug 2009, Sebastian Siebert schrieb:
>[email protected] schrieb:
>> ich möchte ein Programm (sources, Makefile) auf einer 64bit Maschine auch für 32bit
>> bauen. Was brauche ich (ausser den 32bit-Versionen der devel Pakete, die bei
>> der 64-bit Variante benötigt werden) noch.
>> Ich habe gcc 4.1.0 installiert, und in /usr/lib/gcc gibt es nur einen Ordner
>> i586-suse-linux/2.95.3/

v.a.: GCC-Flag '-m32'. Und einen passende i586-* oder so 'target' beim
'./configure'.

>Ich würde dir OBS (openSUSE Build Service) ans Herz legen.
><https://build.opensuse.org/>
>
>Die Pakete kannst du entweder öffentlich zugänglich machen oder auch
>nicht. Du musst dich nur einmal intensiv mit OBS auseinander setzen.
>Danach geht es verdammt schnell mit dem Paketbau. *Versprochen* :-)

Naja, nur wenn alles passt. Wenn's mal hakt, dann gerne kräftig.

>Falls du mit dem Schreiben einer SPEC-Datei nicht so bewandert bist.
>Dann würde ich dir empfehlen, eine SPEC-Datei aus irgendeinem
>OBS-Project zu entnehmen und diese dann anpassen.

Selbst wenn's lokal durchläuft, das rpmlint erfordert meist noch
diverse (sinnvolle) Änderungen am Spec oder Patches an den Sourcen und
und und. Und das ggfs. je nach SuSE-Version unterschiedlich.

Selbst für sehr erfahrene .spec-Bastler wie mich hält das OBS einige
unschöne Überraschungen bereit, für deren Behebung man je nach Fall
einiges an Erfahrung mit .specs, make (oder was auch immer), und der
Programmiersprache braucht.

Besonders spaßig wird's mit Build-Programmen, die sich nicht so
einfach wie make auch via (Umgebungs-)Variablen steuern lassen.

Guck dir mal nur die Schweinereien mittels 'sed' in
https://build.opensuse.org/package/view_file?file=freemedforms.spec&package=freemedforms&project=home%3Adnh%3Atesting
an. Und 'qmake' generiert immerhin noch normale Makefiles.

imake ist auch noch rel. pflegeleicht, dito meist die Perl-Varietäten
(Makefile.PL / Build.PL). Bei denen kann man vieles per make VAR= oder
zur Not make -e VAR= anpassen.

Aber dann guck dir mal cmake, bjam, IIRC smake, ... an. Da sind
irgendwelche Flags für den Compiler hart verdrahtet, oder im besten
Fall in irgendwelchen *systemweit gültigen* Files hinterlegt und nicht
per Kommandozeile änderbar, die aufgrund irgendwelcher Dinge dann
gesetzt werden. Und im OBS kannst du die Systemweiten nicht anpassen!
Da kannst du gar nicht so viel fressen wie du kotzen willst.

Die automake / autotools / make mögen ein großer Haufen Dreck sein (so
bezeichnen sie einige), aber ich als (u.a.) Paketbauer kann da
weitgehend und meist _einfach_ steuern, wie eine bestimmte Datei
gebaut wird, dank weitgehend standardisierter Variablen wie CFLAGS,
CXXFLAGS, LDFLAGS, DESTDIR usw. Ich ziehe die autotools, trotz der
Macken letztlich vor.

Und portabel ist der Kram auch noch. Ich hab mal wget unter Win95 mit
den Buildtools vom Visual Studio 4 oder so gebaut. Ging. Einfach so.
./configure, nmake, nmake install (oder install per Hand, weiß
nimmer). Shell war IIRC cygwin-bash.

Und wenn ich mir die ellenlangen Dateien von cmake / bjam in den
Verzeichnissen so angucke ... Und wie ewig lang (>>10 min) bjam hier
rumeiert, bevor es auch nur das erste Mal den Compiler anwirft (bei
libboost), und dann auch noch scheinbar ziemlich kaputte
Abhängigkeiten der Sourcen/Objects zu haben scheint ...

... ist mir ein simples Makefile.am dann doch lieber. Und die
Makefile.in / Makefile haben eine wohldefinierte Struktur, die sich
aus den Makefile.am ergibt, d.h. auch als Paketbauer reicht es meist
nur ins .am zu gucken.

Äh, *ups*, da bin ich wohl etwas vom Thema abgekommen. Jedenfalls:
deine Empfehlung das OBS zu verwenden ist, ähm, etwas eigenwillig.

Der OP schrieb IIRC nix von nem .spec, das er schon hätte.

Weiter bitte auf opensuse-programming-de.

-dnh

-- 
Ich finde heimwerkende Maenner nur interessant, wenn sie nackt arbeiten.
                                                 -- Regina Hartl