C++将用RHEL4 32位编写的应用程序迁移到RHEL6 64位

Question

我有一系列关于这个问题的问题，并希望保持简单，概念化和可以实际尝试的事情。

我的C++应用程序有许多库，其中一些是第三方的，比如2007年的boost，antlr，libxml2等。我为它们编译了32位库，它们使用-m32标志编译。在方法

问题我非常希望能够通过在64位操作系统RHEL6 32位复制到运行该应用程序，但我看到它与分段故障崩溃。需要对此进行单独分析，我尚未完成。

第二种方法是使用-32位库和32位编译器g ++ 3.4.6在64位上编译应用程序。这编译好。但是，我正在使用boost多线程库获得分段错误。为什么需要更多的调查。

第三种方法，将是非常困难的一个，因为我需要找到一些旧库的源代码也将在64位上重新编译为64位应用程序。

是否还有其他方法可以采用，并且我还错过了我的方法？

Answer 1

有没有其他的方法可以采取，我也错过了 我的方法有什么？

您错过了非常明显的一个：port并将您的应用程序构建为本机64位应用程序。

您当然可以期望在转换到本机64位体系结构时发现问题。但是重要的是要明白，这些问题在你的代码中是真正的bug，在原来的32位平台上直到现在都被隐藏或未被检测到。这将是一个很好的机会找到它们，并解决它们。

在那里，做到了。

迁移过程完成后，您将获得本机64位应用程序，这是具有长期支持的最佳可能情况。恰恰如此，本周的新闻是来自流行的Linux发行版about discontinuing 32 bit support altogether的公告。 32位正在出路。在某些情况下，您将不再有运行32位应用程序的选项（因为没有本地32位Linux发行版，就没有任何理由构建multilib 64/32版本）。做好准备并投入时间，同时有时间有序地将迁移周期设置为64位，然后确定地毯已经从脚下拔出，下一个Linux平台将只有64位，并且您的关键任务应用程序不是64位准备好的。

它也不会让我感到惊讶，因为multilib兼容库的问题是由multilib中的问题和错误造成的。对multilib库的需求不断下降;随着时间的推移，它们的使用越来越少;他们越来越少，支持也越来越少;没有人真的想浪费更多的时间进行测试，并确保它们仍然能够正常工作。