Re: [opensuse-programmin g-de] Re: wie für 32bit übersetzen?

Hallo,

Am Mon, 17 Aug 2009, Sebastian Siebert schrieb:
>David Haller schrieb:
[..]
>> 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.

Eben.

>Sonst würden wir ja nur ein
>floating OS haben, dass ineinander fließt.

Es geht um Konfigurationsdateien wie die von aclocal -- oder eben
konkret um die von bjam.

[..]
>> 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.

Eben.

[..]
>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.

Das ist aber eher selten nötig -- im Normalfalls kannst du alles
relevante per ./configure-Parameter oder make-VARIABLE auf der
Kommandozeile / in der Umgebung übergeben, d.h. bequem von .spec aus,
ohne files zu patchen. Was natürlich auch ginge.

Bei bjam, cmake hab ich's jedenfalls aufgegeben.

[..]
>> Oha. PokerTH. Verwende ich...
>
>Verwenden oder spielen. ;-) Na, dann: Have a lot of fun.

Spielen :) Danke ;)

[..]
>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.

Gute Idee ;)

>> 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...

Diverse Software hat dort Templates / Konfigurationsdateien.
Z.B. tmake und qmake.

Versuche z.B. mal 'qmake' ein '-Wl,-t' oder
'-Wl,-rpath,/opt/irgendwas' in die QMAKE_LFLAGS zu mogeln _ohne_ die
*.pri, *.pro des Projektes zu patchen ... Installiere dir
z.B. QT<next> nach /opt, oder ne andere Version von gcc ... Und
versuch dann dagegen Qt-Kram zu bauen. Da will man eigentlich die
qmake-Vorlagen (.conf) anpassen, damit man nicht immer die .pro ändern
muß. Hab ich hier lokal auch schon öfter gemacht.

Und das geht im OBS prinzipbedingt nicht. Da kommt Freude auf.

-dnh

-- 
"...you want a .sig with that?"