[gcc] Kompilieren und linken eines _einzigen_ Binary von suse 8.2 bis 10.2?
Hallo Liste, mich plagt hier ein "eigentlich" alt bekanntes Problem: Auf der Arbeit liefern wir ein C/C++ Programm an unsere Kunden aus. Unsere Kunden haben von Suse 8.2 bis 10.2 so ziemlich jede Version dazwischen. Als Compiler benutzen wir einen selbst kompilierten gcc 3.3.5... Die einzige "statisch" hinzugelinkte Komponenten ist eine QT 3.3.8 enterprice Version. Alles andere wird dynamisch aus der jeweiligen Distri benutzt. (ARRRRGGGHHH...) Also die jeweiligen "shared object files" aus dem System. Bislang hatte das wohl scheinbar immer irgendwie funktioniert. (na ja, nicht immer. Einige Kunden klagen über undefinierbare Probleme, welche wir hier nicht nachvollziehen können.) Ich hatte mal gelernt, das man immer gut beraten ist ein Programm auf __jeder__ Distri zu kompilieren, für die ich mein Programm ausliefern möchte. So kann ich gefahrlos gegen die dynamischen Libs aus den jeweiligen Systemen linken... Was natürlich den Aufwand distributionsabhängiger Pakete mit sich bringt... Andernfalls muss ich alle Komponenten (libs, etc) statisch dazulinken. So könnte ich ein einziges grosses Binary für unterschiedliche Distri's benutzen. Grundsätzlich bin ich der Meinung das ich alle Komponenten mit dem selben Toolchain bilden bzw. Kompilieren muss. EGAL, ob nun dynamisch oder statisch gelinkt... Schlimm meiner Meinung auch, dass wir distccd benutzen, dieser ist wiederum auf Maschinen mit unterschiedlichen Distris zuhause. Klar alle benutzen den selben Compiler (was ja sein muss!!!), aber diverse Libs werden aus dem System benutzt und die sind bestimmt nicht alle mit dem selben gcc kompiliert worden. Jetzt benötigen wir einen Compiler ab Version 3.4, dieser bringt nun keine libstdc++.so.5 sondern die Version "6" mit. Diese Version wiederum bringt schon meine Suse 10.2 mit. Welche linke ich denn nun? Version der Distri oder Version vom Compiler? Und was ist, wenn ich gegen Libs linke die mit 'nem anderem Compiler compiliert worden sind. Also ich kompiliere mit dem gcc 3.4.6 gegen libs die mit dem gcc 4.1.2 Compiler erstellt worden sind!? Jetzt fängt nämlich erst der ganze Mist an. Programm kompiliert und einwandfrei, stürzt aber unweigerlich bei allen stellen im Programm ab, welche std::stringstream benutzen. Ganz egal ob LD_LIBRARY_PATH auf die libstdc++.s0.6 von 3.4.6 zeigt oder die von dem gcc 4.2.1 (suse 10.2) benutzt (/usr/lib) Kompiliere und linke ich aber nur gegen Komponenten der Distri klappt alles natürlich wie erwartet fehlerfrei... Soweit sogut, liege ich Grundsätzlich richtig? Wenn ja, wo kann ich beweise finden. Die meine Meinung unterstützen? Habe schon auf etliche Seiten in Wikipedia (ABI etc) verwiesen, wo definitiv Aussagen über unterschiedliche ABI Versionen aufmerksam gemacht wird... gcc 3.2 -> 3.4... Als "gentoo" Lover kenne ich das nur so. Benutze ich einen neuen Compiler, wird alles neu kompiliert... Hat der jemand eine Idee? Habe ich falsche Annahmen? Viele Grüsse Andre -- "... one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
* Andre Heine (linux-experience@gmx.net) [20080721 12:08]:
Welche linke ich denn nun? Version der Distri oder Version vom Compiler?
Und was ist, wenn ich gegen Libs linke die mit 'nem anderem Compiler compiliert worden sind. Also ich kompiliere mit dem gcc 3.4.6 gegen libs die mit dem gcc 4.1.2 Compiler erstellt worden sind!?
Statisch linken ist im Grunde kaum noch möglich, erst recht, wenn es sich um C++ Bibliotheken handelt. So funktionieren exceptions z.B. nur, wenn alle Bibliotheken die gleiche dynamische Bibliothek verwenden. Und wenn irgendeine der namensauflösenden Funktionen der glibc (z.B. gethostbyname) verwendet werden soll, *muss* die glibc dynamisch gelinkt werden. Fazit: zumindest libgcc, libstdc++ und glibc sollten *immer* dynamisch gelinkt werden, was ein Programm für alle SuSE Linux/openSUSE Versionen ausschliesst. Philipp --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Montag, 21. Juli 2008 12:18 schrieb Philipp Thomas:
* Andre Heine (linux-experience@gmx.net) [20080721 12:08]:
Welche linke ich denn nun? Version der Distri oder Version vom Compiler?
Und was ist, wenn ich gegen Libs linke die mit 'nem anderem Compiler compiliert worden sind. Also ich kompiliere mit dem gcc 3.4.6 gegen libs die mit dem gcc 4.1.2 Compiler erstellt worden sind!?
Statisch linken ist im Grunde kaum noch möglich, erst recht, wenn es sich um C++ Bibliotheken handelt. So funktionieren exceptions z.B. nur, wenn alle Bibliotheken die gleiche dynamische Bibliothek verwenden. Und wenn irgendeine der namensauflösenden Funktionen der glibc (z.B. gethostbyname) verwendet werden soll, *muss* die glibc dynamisch gelinkt werden.
ACK, man bekommt IMHO auch eine Meldung von Linker/Compiler ...
Fazit: zumindest libgcc, libstdc++ und glibc sollten *immer* dynamisch gelinkt werden, was ein Programm für alle SuSE Linux/openSUSE Versionen ausschliesst.
Ok! Das würde ja meine Aussagen erstmal untermauern... Aber wie sieht das aus, wenn ich __alle__ Abhängigkeiten selber kompiliere und die libstdc++.so.6, etc mitliefere und mit LD_LIBRARY_PATH arbeite? AFAIK kann ich alles mitliefern (ausser glibc glaube ich) und ggf. für unser Programm den LD_LIBRARY_PATH verbiegen?? Das OpenOffice RPM von der openoffice.org z.B. liefert die C++ runtime mit. Das könnte klappen, oder??? Viele Grüsse Andre -- "The algorithm to do that is extremely nasty. You might want to mug someone with it." -- M. Devine, Computer Science 340 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
* Andre Heine (linux-experience@gmx.net) [20080721 12:44]:
AFAIK kann ich alles mitliefern (ausser glibc glaube ich) und ggf. für unser Programm den LD_LIBRARY_PATH verbiegen??
Du hast schon mit libgcc_s.so.1 Probleme (wird implizit gelinkt). Die gibt es nur dynamisch und alle Programme/Bibliotheken müssen die gleiche Bibliothek verwenden, wobei immer die neueste Version der gemeninsame Nenner sein sollte, da libgcc_s.so abwärtskompatibel ist.
Das könnte klappen, oder???
Keine Ahnung (und keine Erfahrung), musst Du einfach ausprobieren. Philipp --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Montag, 21. Juli 2008 13:30 schrieb Philipp Thomas:
* Andre Heine (linux-experience@gmx.net) [20080721 12:44]:
AFAIK kann ich alles mitliefern (ausser glibc glaube ich) und ggf. für unser Programm den LD_LIBRARY_PATH verbiegen??
Du hast schon mit libgcc_s.so.1 Probleme (wird implizit gelinkt). Die gibt es nur dynamisch und alle Programme/Bibliotheken müssen die gleiche Bibliothek verwenden, wobei immer die neueste Version der gemeninsame Nenner sein sollte, da libgcc_s.so abwärtskompatibel ist.
Woran erkennt man, ob eine Library abwärtskompatibel ist? Habe gelesen, das man z.B. ein Programm, dass gegen die libstdc++.so.6.0.3 kompiliert und gelinkt wurde auch auf einem System laufen lassen kann wo z.B. die Version 6.0.8 vorhanden ist. (ABI kompatibel). Version 6.1 z.B. würde schon nicht mehr funktionieren...
Das könnte klappen, oder???
Keine Ahnung (und keine Erfahrung), musst Du einfach ausprobieren.
Hmm, werd' ich wohl machen müssen. Der "Buildservice" wäre mir persönlich lieber... *grrr* Jetzt wo der Quellcode gegen jede GCC Version kompiliert, wäre das für mich schlicht angenehmer;() Egal, was soll's... Vielen Dank schonmal!!! Andre --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, da ich gerade die gleichen Probleme habe, ein Kurzkommentar meinerseits.
Woran erkennt man, ob eine Library abwärtskompatibel ist?
Habe gelesen, das man z.B. ein Programm, dass gegen die libstdc++.so. 6.0.3 kompiliert und gelinkt wurde auch auf einem System laufen lassen kann wo z.B. die Version 6.0.8 vorhanden ist. (ABI kompatibel).
Version 6.1 z.B. würde schon nicht mehr funktionieren...
Bin ich eigentlich der Einzige, der die nichtvorhandene Binärkompatibilität nicht nur ärgerlich, sondern als katastrophal empfindet? Was sind Versionsnummern wert, wenn Bibliotheken schon imkompatibel werden, wenn sich die 2., 3. oder gar 4. Stelle in der Versionsnummer ändert? Sollen doch wieder alle Linuxnutzer ihre Systeme komplett selbst kompilieren? Hat sich schon mal jemand ernsthaft gefragt, warum sich Linux auf dem Desktop nicht durchsetzen kann? Viele Grüße, Tilo Riemer -- Tilo Riemer mailto:riemer@lincvs.org http://www.lincvs.com Oberschöna, Germany --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hi, * Tilo Riemer [2008-07-21 14:05]:
Bin ich eigentlich der Einzige, der die nichtvorhandene Binärkompatibilität nicht nur ärgerlich, sondern als katastrophal empfindet?
Nein.
Was sind Versionsnummern wert, wenn Bibliotheken schon imkompatibel werden, wenn sich die 2., 3. oder gar 4. Stelle in der Versionsnummer ändert? Sollen doch wieder alle Linuxnutzer ihre Systeme komplett selbst kompilieren? Hat sich schon mal jemand ernsthaft gefragt, warum sich Linux auf dem Desktop nicht durchsetzen kann?
Es wurde doch schon einiges in dieser Richtung getan. Siehe http://www.linuxfoundation.org/en/DesktopRelease. Soweit ich weiß gibt es auch eine Toolchain um LSB-konforme Binaries zu erstellen, im Buildservice gibt es soweit ich weiß auch sowas, siehe http://lists.opensuse.org/opensuse-buildservice/2008-03/msg00230.html. Binaries die so erstellt wurden, sollten auf allen LSB-konformen Distributionen laufen. Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am 21.07.2008 um 14:11 schrieb Bernhard Walle:
Es wurde doch schon einiges in dieser Richtung getan. Siehe http://www.linuxfoundation.org/en/DesktopRelease.
Naja, aber das reicht wohl nicht wirklich.
Soweit ich weiß gibt es auch eine Toolchain um LSB-konforme Binaries zu erstellen, im Buildservice gibt es soweit ich weiß auch sowas, siehe http://lists.opensuse.org/opensuse-buildservice/2008-03/msg00230.html.
Binaries die so erstellt wurden, sollten auf allen LSB-konformen Distributionen laufen.
Ich gebe zu, ich müsste erst recherchieren, ob z.B. RHEL 4 und 5 LSB- konform sind. Auf jeden Fall sind sie weit verbreitet. Und da hat man ganz schnell ein Problem, wenn man Software mit Subversion verlinken will. Die für RHEL4 erhältlichen RPMs sind gegen die auf dem System vorhandene Berkeley DB 4.2 gelinkt (auch SVN 1.4.x, obwohl SVN schon vor Jahren auf die BDB > 4.2 umgestiegen ist). Neuere Systeme bringen aber auch eine neuere Berkeley DB mit. D.h. man kann kein Binary eines Programmes erstellen, dass gegen die SVN-Libs und gegen eine Version der Berkeley DB gelinkt ist und auf mehreren Distributionen läuft, ohne sich mit lokal installierten SVN-Versionen ins Gehege zu kommen. Es hilft hier auch nicht, SVN auf RHEL4 selbst zu übersetzen und gegen die aktuelle libdb zu linken. Denn Anwender könnten ja auf RHEL4 auch das gegen die libdb 4.2 gelinkte SVN verwenden wollen, parallel zu dem gegen die aktuelle libdb gelinkte SVN. Das ist in der Konsequenz alles Murks. Viele Grüße, Tilo Riemer PS: Bernd, Du arbeitest jetzt bei SuSE? -- Tilo Riemer mailto:riemer@lincvs.org http://www.lincvs.com Oberschöna, Germany --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
* Tilo Riemer [2008-07-21 14:37]:
Am 21.07.2008 um 14:11 schrieb Bernhard Walle:
Es wurde doch schon einiges in dieser Richtung getan. Siehe http://www.linuxfoundation.org/en/DesktopRelease.
Naja, aber das reicht wohl nicht wirklich.
Jein, es kommt auf die Software an. :)
Soweit ich weiß gibt es auch eine Toolchain um LSB-konforme Binaries zu erstellen, im Buildservice gibt es soweit ich weiß auch sowas, siehe http://lists.opensuse.org/opensuse-buildservice/2008-03/msg00230.html.
Binaries die so erstellt wurden, sollten auf allen LSB-konformen Distributionen laufen.
Ich gebe zu, ich müsste erst recherchieren, ob z.B. RHEL 4 und 5 LSB- konform sind. Auf
LSB 3.1 sicher nicht bei RHEL 4. Aber du kannst Probleme der Vergangenheit nicht mehr in der Zukunft lösen. Wichtig ist, dass es in Zukunft besser läuft.
jeden Fall sind sie weit verbreitet. Und da hat man ganz schnell ein Problem, wenn man Software mit Subversion verlinken will. Die für RHEL4 erhältlichen RPMs sind gegen die auf dem System vorhandene Berkeley DB 4.2 gelinkt (auch SVN 1.4.x, obwohl SVN schon vor Jahren auf die BDB > 4.2 umgestiegen ist). Neuere Systeme bringen aber auch eine neuere Berkeley DB mit. D.h. man kann kein Binary eines Programmes erstellen, dass gegen die SVN-Libs und gegen eine Version der Berkeley DB gelinkt ist und auf mehreren Distributionen läuft, ohne sich mit lokal installierten SVN-Versionen ins Gehege zu kommen. Es hilft hier auch nicht, SVN auf RHEL4 selbst zu übersetzen und gegen die aktuelle libdb zu linken. Denn Anwender könnten ja auf RHEL4 auch das gegen die libdb 4.2 gelinkte SVN verwenden wollen, parallel zu dem gegen die aktuelle libdb gelinkte SVN. Das ist in der Konsequenz alles Murks.
SVN und v.a. die Apache Runtime und Berkley DB scheinen bzgl. Kompatiblität auch ein sehr spezielles Problem zu haben. Ich musste früher mal ein Apacheupdate wegen einer neuen SVN-Version machen, und ich hatte mal ein Endianess-Problem bzgl. der BDB (bei ARM gibt es beides). Seitdem verwende ich nur noch das SVN-eigene Format, das mittlerweile auch Default ist. Letztlich wirst du das BDB-Problem auch unter Windows haben, nur dass du da die Leute leichter dazu bringen kannst, dein "eigenes" SVN mit "eigener" BDB zu verwenden. Oder irre ich?
PS: Bernd, Du arbeitest jetzt bei SuSE?
Offensichtlich. ;) Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Moin moin, Am Montag, 21. Juli 2008 14:05 schrieben Sie:
da ich gerade die gleichen Probleme habe, ein Kurzkommentar meinerseits.
Woran erkennt man, ob eine Library abwärtskompatibel ist?
Habe gelesen, das man z.B. ein Programm, dass gegen die libstdc++.so. 6.0.3 kompiliert und gelinkt wurde auch auf einem System laufen lassen kann wo z.B. die Version 6.0.8 vorhanden ist. (ABI kompatibel).
Version 6.1 z.B. würde schon nicht mehr funktionieren...
Bin ich eigentlich der Einzige, der die nichtvorhandene Binärkompatibilität nicht nur ärgerlich, sondern als katastrophal empfindet?
Stimmt schon, aber ist kein reines Linux Problem. Eher ein Problem von "Standards"... Siehe auch hier: http://de.wikipedia.org/wiki/Bin%C3%A4rschnittstelle Wobei es nicht gesichert ist, ob die Sprünge der ABI Versionen von 3.2 auf 3.4 erfolgte. Auf einer andere Liste (gentoo) sind alle irgendwie der Meinung das der Sprung von 3.3 auf 3.4 erfolgte. Diesem Artikel nach sollte es keine Problem sein, mit dem GCC 3.4.6 binaries zu erzeugen, die man später auf ein System (das z.B. mit dem GCC 4.X kompiliert worden ist) laufen lassen könnte. (libstdc++.so wird ja dynamisch gelinkt) Ja, klappt auch irgendwie. Nur eben nicht immer?! Ich vermisse lediglich eine Information welche Version mit einer anderen funtioniert und was eben nicht geht. Diese Information gibt es bestimmt bei gcc.gnu.org. Leider habe ich sie noch nicht gefunden... Ein weiteres Problem mit unserem Projekt ist, dass wir hier ein OpenOffice Paket (inkl. SDK) von openoffice.org benutzen (warum?? Keine Ahnung). Da liegt nochmal einen andere libstdc++ bei. Jetzt muss ich irgendwie mit _drei_ unterschiedlichen "libstdc++" Versionen umgehen (und das nur auf 10.2) libstdc++.so.6.0.3 # gcc 3.4.6 libstdc++.so.6.0.8 # gcc 4.1.2 libstdc++so.6.1 # gcc unknown
Was sind Versionsnummern wert, wenn Bibliotheken schon imkompatibel werden, wenn sich die 2., 3. oder gar 4. Stelle in der Versionsnummer ändert? Sollen doch wieder alle Linuxnutzer ihre Systeme komplett selbst kompilieren? Hat sich schon mal jemand ernsthaft gefragt, warum sich Linux auf dem Desktop nicht durchsetzen kann?
Hmm. Der Benutzer bekommt ja eigentlich nichts davon mit. der Distributor erstellt ja alle Pakete und so hat er ja erstmal immer zusammenpassende Versionen. Erst, wenn der User anfängt rumzufuschen uznd z.B. 9.3 Pakete mit einer 10.3 mischen will. Das Problem ist eigentlich nur ärgerlich für Software Hersteller;-) Und da eigentlich auch nur, wenn man sich um diesen "Versions-Kram" keine Gedanken macht. Es funktioniert noch einfach zuviel mit diesem "gemische". Mein Problem ist eigentlich nur eines: Wie bringe ich meinen Chef dazu, das er erkennt das wir schlicht korrekt erstellte Pakete auszuliefern müssen. (Ohne Hickhack, sondern für für jede Distri ein Paket. Alles andere ist IMHO SUCKS) Dieses Problem lässt sich ja ganz elegant umschiffen, man könnte ja den Buildservice benutzen. Damit hatten wir schonmal in meiner alten Firma gearbeitet. Du musst dann lediglich deinen Code sauber halten... Dieses Problem ist selbst unter W2K da, da haben wir gerade genauso Probleme. (Umstieg vc++6 auf .Net Version 9 dreck). Auch hier ist es die c++ runtime, massive Problem mit std::string... Eigentlich alles egal mit den Versionen, wenn man diese Fallstricke beachtet. Nur man muss sie eben beachten;() Man fängt nur an zu straucheln, wenn vorher schon alles denkbare falsch bzw. schief gelaufen ist. Viele Grüsse Andre --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
participants (4)
-
Andre Heine -
Bernhard Walle -
Philipp Thomas -
Tilo Riemer