Re: Re: wie für 32 bit übersetzen?

David Haller schrieb:
> Hallo,
> 
> Am Son, 16 Aug 2009, Sebastian Siebert schrieb:
>> David Haller schrieb:
>>> Erstmal: dieses und ähnliche Themen gehören _eindeutig_ auf
>>> opensuse-programming-de.
>>> X-Mailed & F'up dahin.
> 
> Sach mal, hast du das überlesen?
> 
> Das war mehr als nur eine dezente Bitte. 
> 

Irgendwie schon... ;-)

>>> Am Son, 16 Aug 2009, Sebastian Siebert schrieb:
> [..]
>>>> 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.
>> Wenn du irgendwelche System-Libraries meinst, die im System tief
>> verankert. Dann ja.
> 
> Du willst alle nicht-System-Libraries selber mit in deinem OBS-Project
> mit kompilieren? Das arme OBS.
> 

Nun ja, wie man's nimmt. :-)

>>>> 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.
>> Bisher ist es zu meinen Gunsten gelaufen. Nur Glück oder vom Upstream
>> sauber programmiert, wobei ich eher Letzteres tippe.
> 
> Sehr, sehr wahrscheinlich letzteres. _Und_ Glück ;)

Jepp...

>>> 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.
>> Ah, David, diese Schweinerei hast du dem Upstream-Autoren zu verdanken,
>> dass diese nicht die notwendige Flexibilität verbauen, dass hat mit OBS
>> wenig zu tun.
> 
> Eben. Vom Upstream kommt viel, das "Schweinkram" erforderlich
> macht. In jeder neuen Version wieder (anders).
> 
> Aber das OBS verhindert (praktisch), daß man sowas einfach mal
> systemweit flicken kann, sondern das jedesmal im Spec machen muß.
> 

Systemweit geht es aber nicht so einfach. Sonst würden wir ja nur ein
floating OS haben, dass ineinander fließt. Wobei wir schon beim Update
wohl eher Upgrade auf eine neue glibc schon das gesamte System zum
Neubau zwingt. Dann wären wir wieder bei Gentoo und dort wird auch schon
wie blöde rumgefrickelt und sämtlich Libraries neuzubauen. Bei Gentoo
geht einfach zuviel Zeit drauf, womit man beim OBS "eigentlich" wieder
einspart, weil der Normalverbraucher darum nicht mehr kümmern muss.

>>> 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.
>> Meist stehen diese Anpassung in diversen Readme-Dateien oder auf der
>> Webseite vom Upstream, wie man was ändert. Manchmal kann man gar nichts
>> ändern und muss sich mit einigen Patch-Dateien behelfen. Dies ist
>> normal und macht jede andere Distro auch. In diesem Fall muss man sich
>> an das Upstream wenden, um besser Anpassungsfähigkeiten zu ermöglichen.
> 
> Ich hab nix gegen patches. Aber nur um $prefix oder LDFLAGS zu ändern?
> 

Ist mir auch schon passiert, keine Bange. Aber ich wüsste dazu auch
keine andere Lösung als eben die Spec-Datei mit allen Patches dazu zu
schreiben, worin man die Änderungen zentral festhalten und ausführen
kann. Wenn mal z.B. im openSUSE 10.3 beim Bau meckert, dann wird kurzen
Prozess gemacht und eine Weiche in die Spec-Datei eingebaut, weil ggfs.
die restlichen Libraries zu alt sind, um diese anders zu linken oder
bestimmte Funktionen auszuschalten.

>>> 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.
>> Wende dich an die Leute vom Upstream. Man kann gar nicht genug
>> wiederholen. :-)
> 
> Du meinst, die boost-Leutkens würden wg. mir von bjam auf automake
> umsteigen?

Die Boost-Leutkens sind auch nur Menschen und haben halt ein neues
Werkzeug für den Bau von Boost kreiert. Die Erfahrung machen wir nun mal
alle jetzt.

>>> 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.
>> Von automake oder autotools sollte man mit Abstand genießen. Da evtl.
>> wichtige Flags überschrieben werden. Hier muss man 3 Mal kontrollieren,
>> ob wirklich alles richtig gelaufen ist.
> 
> Ist immer noch viel einfacher. Und überschreiben muß man i.d.R. gar
> nichtmal, da es bei sauber generierten Makefiles Variablen gibt, über
> die man gezielt seine Flags reinbringen kann.
> 

Und kannst du auch in automake bzw. autotools systemspezifische Schalter
für bestimmte openSUSE Versionen für den Bau betätigen? Nein. Daher
fällt das ganze wieder auf die Spec-Datei, um die "configure.ac"-Datei
bzw. "Makefile.am" zu modifiziern und abschließend ein autoreconf
auszulösen.

>>> 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.
>> Wenn es keine große Abhängigkeiten gibt, dann haben die vom Upstream
>> gute Arbeit geleistet, dass es wenigstens läuft. :-)
> 
> Jup. wget ist sauber.
> 

Gut, da sind wir ja einer Meinung. :-)

>>> 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 ...
>> Mit libboost kann ich auch was erzählen. Da gab es ein "hash resize"
>> bug, der jetzt behoben wurde. Ich bin für den Paketbau von PokerTH
>> zuständig und dieses Paket benötigt halt libboost. Das PokerTH-Team
>> (Upstream) hat mir mitgeteilt, dass das libboost 1.39 ein Fehler hat.
> 
> Oha. PokerTH. Verwende ich...

Verwenden oder spielen. ;-) Na, dann: Have a lot of fun.
Aber nur eines Vorweg. Damals als ich PokerTH 0.6.3 im OBS bauen ließ,
hatte mein Vorgänger die libboost 1.36 statisch gelinkt. Auf Nachfrage
an das OBS-Team, ob ich die neue Boost 1.38 weiterhin statisch verlinken
kann, gab es bei denen haue haue auf die Finger. So beschloß ich,
die libboost zu entkoppeln und diese einfach nur gegen zu linken. Da
musste ich praktisch die ganze Spec-Datei anfassen bzw. wohl eher
neuschreiben, weil da einfach das Chaos ausgebrochen war, um
irgendwelche Merkwürdigen Lecks mit sed und awk zu schließen. Wegen dem
guten Kontakt zum Upstream benötige ich die Tools sed und awk nicht
mehr. Mehr Kommunikation unter uns Paketbauern würde nicht schaden.
Hierfür müssten wir eine WIKI-page für jedes Package mit sämtlichen
Abhängigkeiten erstellen, um mögliche Konflikte mit *ALLEN*
abzusprechen.

>> Wobei der Server von PokerTH abkratzen kann. Hört sich schlimm an, ist
>> aber mit einem Patch schnell behoben. Ich habe bereits ein Fehlerpatch
>> an das OBS-Team der Factory gesendet und habe es eingepflegt. So, und
>> wenn noch was kaputt ist, dann wende dich an das Upstream. (Habe ich das
>> nicht eben schon gesagt?!) In dem Fall war es beim Upstream der Fehler
>> bekannt und ein Patch stand zu Verfügung.
> 
> libboost ist IMO v.a. nervig. Nervig zu kompilieren (klappt hier mit
> keiner bisher probierten 1.3x Version, weder mit gcc-2.93.3, noch
> 3.3.5), nervig den von diversen Programmen (angeblich) geforderten
> Versionen hinterherzuhecheln ...
> 
> AFAIK fluchen auch die Packager der Versionen der OpenSUSE Releases
> gerne mal über libboost ...
> 

Ja, jüngsten habe ich mitbekommen, dass es ziemliche Probleme mit Boost
und OpenOffice gab. Auch wegen dem "hash resize". *roll_eyes*
Mittlerweile habe ich auf gut Zureden das Upstream-Team überzeugen
können, noch nicht auf Boost 1.39 und qt 4.5.2 umzusteigen, weil es eben
zu wenig erprobt ist. Um genau zu sein, wäre es für openSUSE 11.2 echt
fatal, wenn irgendwelche Anwendungen wegen fehlerhaften Libraries
abstürzen.

>>> ... 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.
>> Das wahrlich die einfachste Lösung, wenn der Upstream halt sauber
>> gearbeitet hat.
> 
> Bei autotools/automake kann man das recht einfach auch noch per
> Kommandozeile oder patch (von configure, aclocal.m4, ...) _zentral_
> aber lokal, auch im OBS, reparieren, da es eine build-lokale Datei
> betrifft.  Aber wie willst du (als non-root-build) sauber in
> /usr/{lib,share}/irknwas was patchen?
> 

Was willst du eigentlich im Nachhinein in /usr/{lib,lib64}
rumfummeln? Leuchtet mir nicht ein, sorry. Eigentlich patcht man vorher
in den Quellen. Und nicht wenn es fertig ist!!! Hm...


Gruß

Sebastian
-- 
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]