Linkflags => abhängige Dateien mit ins RPM aufnehmen
Hallo, ich bekomme auf meine Postings in Google leider keine Antworten. Nun ist es vielleicht auch ein allgemeines Problem. Ich verwende ein Framework (wxWidgets), gegen das ich meine Quellen linke. Dies geht ja, da die Linkflags einfach zu erfragen sind. Nur mein Problem ist, die Shared Libraries auch automatisch in mein RPM Paket zu bekommen. Das Problem ist, wenn jemand mein SRPM verwendet, um selbst ein RPM Paket zu erstellen, muss bis jetzt immer geprüft werden, ob auch die richtigen Shared Libraries eingepackt werden. Diese Libiaries sollen nicht unbedingt in das Paket für ein Programm gepackt werden, aber wenigstens soll es automatisch ein abhängiges Paket erstellen, das dann bei Bedarf nachgezogen werden kann. (Ein Vendor RPM für mehrere Programme des Herstellers) Hat jemand schonmal daran gearbeitet, aus wx-config --libs oder ähnlichen config Scripten mit Linkflag Parametern die benötigten Dateien zu generieren ? Also aus -lwx_gtk2_core_Lollisoft -lwx_gtk2_gl_Lollisoft und so weiter eine Liste der dahinter stehenden Dateien. Wenn dies irgendwie möglich ist, kann sich jeder einfach daran beteiligen, auf verschiedenen Plattformen RPM Pakete zu erstellen, ohne von Hand eingreifen zu müssen. Danke, Lothar -- Lothar Behrens | Rapid Prototyping ... Heinrich-Scheufelen-Platz 2 | 73252 Lenningen | www.lollisoft.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hi, On Friday, September 14, 2007 at 13:16:59, Lothar Behrens wrote:
Ich verwende ein Framework (wxWidgets), gegen das ich meine Quellen linke. Dies geht ja, da die Linkflags einfach zu erfragen sind. Nur mein Problem ist, die Shared Libraries auch automatisch in mein RPM Paket zu bekommen.
Warum würdest du shared libs die nicht von deiner software sind in das Paket einpacken? Das macht nicht so wirklich sinn. In dem System, in dem du baust, kommen die ja auch wahrscheinlich nicht von irgendwo her sondern aus anderen Paketen. Also Autoreqprov anmachen in deinem spec file und zur not Requires von hand setzen. Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am 14.09.2007 um 13:24 schrieb Henne Vogelsang:
Hi,
On Friday, September 14, 2007 at 13:16:59, Lothar Behrens wrote:
Ich verwende ein Framework (wxWidgets), gegen das ich meine Quellen linke. Dies geht ja, da die Linkflags einfach zu erfragen sind. Nur mein Problem ist, die Shared Libraries auch automatisch in mein RPM Paket zu bekommen.
Warum würdest du shared libs die nicht von deiner software sind in das Paket einpacken? Das macht nicht so wirklich sinn. In dem System, in dem du baust, kommen die ja auch wahrscheinlich nicht von irgendwo her sondern aus anderen Paketen. Also Autoreqprov anmachen in deinem spec file und zur not Requires von hand setzen.
Ich habe Autoreqprov auf on gesetzt. Beim installieren meines Paketes gibt es auch Mecker von Yast. Nun hat SuSE die Abhängigkeit nicht automatisch aufgelöst, da ich nicht gegen eine SuSE Variante von wxWidgets gelinkt hatte. Ich hatte schon versucht, auf VMWare ein OpenSuSE 10.2 (zwecks neuerem wxW) als neues Testsystem zu verwenden. Nur hat das noch nicht funktioniert. Mir ist nicht bekannt, ob es für SuSE 9.1 mindestens ein wxWidgets 2.6.3 gibt. Zudem ist auf den Herstellerseiten von wxWidgets kein RPM zu finden. In den wxWidgets mailings wird oftmals empfohlen ein static Build zu machen, was bei mir aber nicht geht. Mit einem Static Build hat man dann weniger Abhängigkeitsprobleme. Also baue ich meine wxWidgets Library mit einem Vendor tag um nicht in Konflikt mit evtl. vorhandenen Libraries zu kommen. Allgemein glaube ich, mehr Linux Distros abdecken zu können, wenn ich das so mache. Mal abgesehen davon, ob GTK1 oder GTK2 installiert ist. Heute dürfte per se GTK2 installiert sein. Glaube ich :-) Und weiter, wenn einer lieber gegen andere Library Versionen linken will, ist ja immer noch ein TGZ release verfügbar, oder ich baue zwei RPM Varianten. Was ich möchte, ist das die manuelle Nachinstallation und / oder das kompilieren zu vermeiden. Es soll eine Variante darstellen, nicht generell für Alle die einzige Möglichkeit, an mein Programm zu kommen. Lothar
Henne
-- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
-- Lothar Behrens | Rapid Prototyping ... Heinrich-Scheufelen-Platz 2 | 73252 Lenningen | www.lollisoft.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Fri, 14 Sep 2007 14:16:46 +0200, Lothar Behrens wrote:
Mir ist nicht bekannt, ob es für SuSE 9.1 mindestens ein wxWidgets 2.6.3 gibt. Zudem ist auf den Herstellerseiten von wxWidgets kein RPM zu finden.
Was hindert Dich daran, ein openSUSE-Projekt aufzumachen und dann die aktuelle wxGTK für SLES9 zu bauen? Das müsste auch auf der 9.1 funktionieren.
In den wxWidgets mailings wird oftmals empfohlen ein static Build zu machen, was bei mir aber nicht geht.
Warum ist es Dir nicht möglich, nur wxGTK statisch einzubinden?
Also baue ich meine wxWidgets Library mit einem Vendor tag um nicht in Konflikt mit evtl. vorhandenen Libraries zu kommen.
Das funktioniert mit AutoReqProv: on nicht! Da müsstest Du schon entweder den Bibliotheken einen anderen Soname geben (mach mal spasseshalber ein 'rpm -q --provides' auf Dein Bibliothekspaket, dann siehst du, was ich meine) oder aber mit Pseudo-Abhängigkeiten arbeiten, also z.B. in Deinem Programm-Paket ein Requires: wxGTK-Lollisoft und in Deinen wxGTK-Paketen Provides: wxGTK-Lollisoft natürlich für jedes Bibliothekspaket ein anderes Provides-Tag verwenden. Das müsste problemlos funktionieren.
Allgemein glaube ich, mehr Linux Distros abdecken zu können, wenn ich das so mache.
Das macht keinen Sinn. Entweder Du beschränkst Dich auf die von der LSB normierten Symbole (dann ist aber wxGTK aus dem Spiel :), dann kannst Du das Programm zumindest auf LSB konformen Distris laufen lassen, oder Du baust für jede Distribution separate Pakete, oder du bindest alle unsicheren Kandidaten statisch ein. Aber schon die glibc kannst Du in den meisten Fällen nicht statisch einbinden (statisch Linken verbietet sich bei Verwendung von Funktionen zur Namensauflösung wie z.B. gethostbyname, sprich wenn Funktionen aus den libnss* Bibliotheken gebraucht werden).
Mal abgesehen davon, ob GTK1 oder GTK2 installiert ist. Heute dürfte per se GTK2 installiert sein. Glaube ich :-)
Aber nicht unbedingt auf einer 9.1 :) Und nicht zwingend in der Version, gegen welche die wxGTK gelinkt wurde. Philipp --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am 15.09.2007 um 04:11 schrieb Philipp Thomas:
On Fri, 14 Sep 2007 14:16:46 +0200, Lothar Behrens wrote:
Mir ist nicht bekannt, ob es für SuSE 9.1 mindestens ein wxWidgets 2.6.3 gibt. Zudem ist auf den Herstellerseiten von wxWidgets kein RPM zu finden.
Was hindert Dich daran, ein openSUSE-Projekt aufzumachen und dann die aktuelle wxGTK für SLES9 zu bauen? Das müsste auch auf der 9.1 funktionieren.
Meinst Du ein RPM von openSuSE 10.1 downloaden und auf 9.1 bauen ? Nicht das Bauen der wxGTK ist das Problem, sondern das bundeln ohne zu wissen wie die wxGTK gebaut wurde. (Von hand geht das ja - makefile / spec ändern) Ich meine, wenn einer ein Packet baut, dass Seine Software enthält, aber nicht immer (als Modul, so wich ich Fremdsoftware einbinden kann) schauen muss, ob die wxGTK Library richtig gebaut ist. Beispielsweise ist diese einfach schon installiert. Das beste bleibt wohl auf dem Zielsystem alles bauen. Dann sollte es auch gehen. Nur hatte ich gedacht, zwischen 9.1 und 10.1 keine Probleme zu bekommen. Ich hatte Probleme mit libexpat.so.0, es war libexpat.so.1 installiert. Also lieber auf einem 10.1er bauen :-)
In den wxWidgets mailings wird oftmals empfohlen ein static Build zu machen, was bei mir aber nicht geht.
Warum ist es Dir nicht möglich, nur wxGTK statisch einzubinden?
Ich setze grundsätzlich auf Plugins und nachladbare Software. Oder kann ich meine Module gegen die executable binden ?
Also baue ich meine wxWidgets Library mit einem Vendor tag um nicht in Konflikt mit evtl. vorhandenen Libraries zu kommen.
Das funktioniert mit AutoReqProv: on nicht! Da müsstest Du schon entweder den Bibliotheken einen anderen Soname geben (mach mal spasseshalber ein 'rpm -q --provides' auf Dein Bibliothekspaket, dann siehst du, was ich meine) oder aber mit Pseudo-Abhängigkeiten arbeiten, also z.B. in Deinem Programm-Paket ein
Requires: wxGTK-Lollisoft
und in Deinen wxGTK-Paketen
Provides: wxGTK-Lollisoft
natürlich für jedes Bibliothekspaket ein anderes Provides-Tag verwenden. Das müsste problemlos funktionieren.
Das ist es, was mir gefehlt hat. Grundsätzlich dachte ich mir das so (--with-flavour=Lollisoft).
Allgemein glaube ich, mehr Linux Distros abdecken zu können, wenn ich das so mache.
Das macht keinen Sinn. Entweder Du beschränkst Dich auf die von der LSB normierten Symbole (dann ist aber wxGTK aus dem Spiel :), dann kannst Du das Programm zumindest auf LSB konformen Distris laufen lassen, oder Du baust für jede Distribution separate Pakete, oder du
Also ist mein Ansatz schon richtig (--with-flavour=Lollisoft), aber am Beispiel der libexpat und allgemein an dem Versions System (lib<abc>.so.<major>.<minor>.<micro>) kann ich nicht sicherstellen, dass es so geht.
bindest alle unsicheren Kandidaten statisch ein. Aber schon die glibc kannst Du in den meisten Fällen nicht statisch einbinden (statisch Linken verbietet sich bei Verwendung von Funktionen zur Namensauflösung wie z.B. gethostbyname, sprich wenn Funktionen aus den libnss* Bibliotheken gebraucht werden).
Mal abgesehen davon, ob GTK1 oder GTK2 installiert ist. Heute dürfte per se GTK2 installiert sein. Glaube ich :-)
Aber nicht unbedingt auf einer 9.1 :) Und nicht zwingend in der Version, gegen welche die wxGTK gelinkt wurde.
Eben doch fast immer damit zu rechnen ist, dass die Versionen NICHT passen :-( Also: Suche ich lieber nach Leuten, die ich als Packager gewinnen kann :-) Aber allgemein: Ich suche demnächt wieder Tester. Ich bin dabei meine SW in 1.0rc2 zu veröffentlichen. Die 1.0rc1 ist leider nicht ohne Fehler. Mehr zu der SW auf meiner Webseite und http://sourceforge.net/projects/lbdmf Das Thema ist unten ja zu sehen :-) Lothar
Philipp --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
-- Lothar Behrens | Rapid Prototyping ... Heinrich-Scheufelen-Platz 2 | 73252 Lenningen | www.lollisoft.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
participants (3)
-
Henne Vogelsang -
Lothar Behrens -
Philipp Thomas