Question

我已经在OSX便携式计算机上成功编译并执行了一些代码，现在正尝试将项目移至运行Scientific Linux的HPC。

代码似乎可以正确编译和链接，但是当我运行可执行文件时，它会中止：

抛出'H5 :: DataSpaceIException'实例后调用
terminate
中止（核心已弃用）

我在程序的第一行应执行的行上放置了一条打印语句，但从未到达此行，即程序在执行第一行之前就终止了。

我已将问题隔离到特定的库，即在不使用库的情况下进行编译时，一切正常（除了临时删除的依赖库的函数）。当包含该库时，它会如上所述编译但中止。我已将同一库链接到使用它的其他可执行文件而没有问题：与我链接到的其他库是否存在一些冲突？

我对C ++还是很陌生，对于这种调试也很陌生。这是程序终止时来自gdb的回溯：

#0  0x00002aaaad82a1f7 in raise () from /lib64/libc.so.6
#1  0x00002aaaad82b8e8 in abort () from /lib64/libc.so.6
#2  0x00002aaaad337ac5 in __gnu_cxx::__verbose_terminate_handler() () from /lib64/libstdc++.so.6
#3  0x00002aaaad335a36 in ?? () from /lib64/libstdc++.so.6
#4  0x00002aaaad335a63 in std::terminate() () from /lib64/libstdc++.so.6
#5  0x00002aaaad335c83 in __cxa_throw () from /lib64/libstdc++.so.6
#6  0x00000000020ec521 in H5::DataSpace::getConstant() ()
#7  0x0000000000da8dff in _GLOBAL__sub_I_H5DataSpace.cpp ()
#8  0x00000000024ecdcd in __libc_csu_init ()
#9  0x00002aaaad816b95 in __libc_start_main () from /lib64/libc.so.6
#10 0x0000000000dab7a7 in _start ()
(gdb)

我真的不知道从哪里开始解释这一点。我想将其与笔记本电脑上工作版本的回溯进行比较。如果我在main处设置一个断点（我知道该断点不会在Linux版本中执行），请运行并打印回溯，我会得到：

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x0000000100003490 antsRegistration`ants::antsRegistration(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >, std::__1::basic_ostream<char, std::__1::char_traits<char> >*)
frame #1: 0x000000010000306e antsRegistration`main + 62
frame #2: 0x00007fff5abc3115 libdyld.dylib`start + 1

看起来实际上更像源代码，但是没有帮助我识别出任何区别。这里欢迎您提供任何见识或调试策略。

Answer 1

在将OpenGL程序从OSX移植到Windows时，我遇到了类似的问题。 OSX至少在OpenGL世界中只是做一些不同的事情。最后，我必须根据编译的目标进行OSX和Win特定的函数调用。

如果遇到此问题，我将检查在“故障”库中实现的功能，也许逐一介绍它们，并尝试找出哪个调用造成了损害。与主程序隔离进行此操作-我的意思是在一个单独的最小程序中，该程序完全清楚没有发生任何其他副作用。

然后，您将可以更好地了解有问题的特定功能（如果仍然需要，还可以针对非常具体的问题）

在Linux中链接但在OSX中链接时库冲突

1 个答案: