Am Mittwoch, 21. Dezember 2005 09:29 schrieb Philipp Thomas:
On Wed, 21 Dec 2005 01:36:14 +0100, Jan Ritzerfeld wrote:
Aber unter SL 10.0 (mit dem gcc_old-2.95.3-92.i586.rpm von ftp.suse.com oder einem selbstkompilierten)
Sprich in beiden Fällen mit einem gcc 2.95.3?
Richtig. Unter SL 8.1 und 10.0 mit dem gcc 2.95.3, unter SL 7.x mit dem 2.95irgendwas (dem gcc von den CDs).
schmeißen C++-Exception ein SIGABRT, sobald diese Exceptions in hinzugelinkten Komponenten geworfen werden.
*Alle* beteiligten Komponenten inklusive der Bibliotheken (sofern es C++ Bibliotheken sind) *müssen* mit 2.95.3 kompiliert worden sein, da sich zwischen 2.95.3 und 4.0.2 mindestens zweimal das C++ ABI inkompatibel geändert hat.
Jau. Gibt lustige Fehler. Aber hauptsächlich beim kompilieren. Es werden in diesem Projekt alle Libraries selbst kompiliert und nur die aus dem Projekt benutzt, um eben unabhängig von dem eigentlichen System zu sein. Die libstdc++ wird auch aus dem entsprechenden gcc-Verzeichnis benutzt. Und der Witz ist ja, daß es unter SL 8.1 mit dem gcc 2.95.3 wunderbar funktioniert.
Wenn es das nicht ist, müsste ich mal versuchen, mich intern schlau zu machen.
Das wär klasse. Das was noch aus dem System benutzt wird ist die glibc, insbesondere /lib/ld-2.3.x.so. Und SL 8.1 und 10.0 basieren ja auf unterschiedlichen glibc-Versionen. Ein einfaches Beispielprogramm, bei dem das Problem auch auftritt, habe ich leider nicht hinbekommen. Das Problem tritt scheinbar nur dann auf, wenn man mehrere Objekt-Dateien mit selbstkompilierten Libraries zusammenlinkt. Letztlich verhält sich das Programm so, als hätte man eine Exception geworfen, die nicht gefangen wird bzw. werden kann, weil es kein passendes catch gibt. Aber es sind selbstdefinierte Exception-Objekte, die eigentlich alle mit catch(exception& e) gefangen werden müßten. TIA Jan -- You can't guard against the arbitrary.