C++ Migration von in RHEL4 32bit auf RHEL6 geschrieben 64bit

Question

Ich habe eine Reihe von Fragen in Bezug auf diese und wollen Dinge einfach, konzeptionell und etwas, die praktisch ausprobiert werden können.

Meine C++ Anwendung hat viele Bibliotheken von denen einige von Drittanbietern sind wie boost, antlr, libxml2 usw. von 2007. Ich habe 32bit Bibliotheken für sie mit -m32 Flag kompiliert.

Fragen zum Ansatz ich würde im Idealfall in der Lage sein will, durch das Kopieren von 32bit auf 64bit RHEL6 os die Anwendung auszuführen, aber ich sehe, dass es mit Segmentation Fault abstürzt. Brauchen separate Analyse für diese, die ich noch nicht abgeschlossen habe.

Der zweite Ansatz bestand darin, die Anwendung auf 64-Bit mit -m32 unter Verwendung aller 32-Bit-Bibliotheken und 32-Bit-Compiler g ++ 3.4.6 zu kompilieren. Das kompiliert ok. Aber ich bekomme Segmentierung Fehler mit Boost Multi-Thread-Bibliotheken. benötigt etwas mehr Untersuchung, warum.

Dritter Ansatz und wird sehr schwierig sein, wie ich den Quellcode für einige der alten Bibliotheken zu finden wird auch auf 64 Bit als 64-Bit-Anwendung neu kompilieren werden.

Gibt es noch andere Ansätze, die ich übernehmen kann, und habe ich etwas in meinem Ansatz übersehen?

Answer 1

Gibt es andere Ansätze, die ich nehmen kann und auch habe ich etwas in meinem Ansatz vermissen?

Sie vermissen die sehr offensichtliche: Port und bauen Sie Ihre Anwendung als native 64-Bit-Anwendung.

Sie können sicherlich Probleme beim Übergang zu einer nativen 64-Bit-Architektur erwarten. Es ist jedoch wichtig zu verstehen, dass diese Probleme echte Fehler in Ihrem Code sind, die bisher auf der ursprünglichen 32-Bit-Plattform versteckt oder nicht erkannt wurden. Dies wird eine ausgezeichnete Gelegenheit sein, sie zu finden und zu beheben.

Da gewesen, das getan.

Nachdem der Migrationsprozess abgeschlossen ist, erhalten Sie am Ende eine native 64-Bit-Anwendung, die bestmögliche Situation in Bezug auf langfristige Unterstützung. Es passiert einfach, dass in den Nachrichten dieser Woche Ankündigungen von populären Linux-Distributionen about discontinuing 32 bit support altogether sind. 32 Bit ist auf dem Weg nach draußen. Irgendwann haben Sie keine Möglichkeit mehr, 32-Bit-Anwendungen auszuführen (da es keine nativen 32-Bit-Linux-Distributionen gibt, gibt es keinen Grund, Multilib-64/32-Versionen zu erstellen). Es ist besser, vorbereitet zu sein und Zeit zu investieren, während es Zeit für einen geordneten Migrationszyklus auf 64 Bit gibt. Um dann herauszufinden, dass Ihnen der Teppich unter den Füßen weggezogen wurde, wird Ihre nächste Linux-Plattform nur 64 Bit lang sein Ihre unternehmenskritische Anwendung ist nicht 64-Bit-fähig.

Es wird mich auch nicht überraschen zu erfahren, dass die Probleme, die Sie mit Multilib-Kompatibilitätsbibliotheken haben, auf die Probleme und Fehler in den Multilib-Builds selbst zurückzuführen sind. Die Nachfrage nach Multilib-Bibliotheken geht weiter zurück; sie werden immer weniger benutzt, wenn die Zeit vergeht; und sie erhalten immer weniger und weniger Unterstützung; und niemand möchte wirklich mehr Zeit damit verschwenden, Tests zu machen und sicherzustellen, dass sie immer noch funktionieren.