NLi10Me
NLi10Me

Reputation: 3292

Library conflict when linking in Linux, but not OSX

I have successfully compiled and executed some code on my OSX laptop, and am now attempting to move the project to an HPC running Scientific Linux.

The code seems to compile and link properly, but when I run the executable it aborts:

terminate called after throwing an instance of 'H5::DataSpaceIException'
Aborted (core dumped)

I put a print statement at what should be the first executed line of the program, but this line is never reached, i.e. the program is terminated before the first line is executed.

I have isolated the problem to a specific library, i.e. when compiling without the library everything works (except for the temporarily removed functions which rely on the library). When the library is included, it compiles but aborts as above. I have linked this same library to other executables which use it without issue: is there some conflict with other libraries I'm linking to?

I'm pretty new to C++, and also new to this kind of debugging. Here is the backtrace from gdb for when the program aborts:

#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)

I really don't know where to start to interpret this. I thought to compare it to a backtrace for the working version on my laptop. If I put a breakpoint at main, which I know doesn't execute in the Linux version, run, and print a backtrace I get:

* 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

which looks a lot more like the source code actually, but doesn't help me identify any differences. Any insight or debugging strategy here would be welcome.

Upvotes: 1

Views: 564

Answers (1)

bcperth
bcperth

Reputation: 2291

I had similar problems porting OpenGL programs from OSX to Windows. OSX simply does some thing differently at least in the OpenGL world. In the end I had to make OSX and Win specific function calls depending on the target of the compile.

If I had this problem, I would examine the functions that are implemented in the "faulty" library, perhaps introducing them one by one and try to find out which call is doing the damage. Do this in isolation from the main program - I mean in a separate minimal program, where its totally obvious that no other side effects are happening.

Then you are in a better position to read up about the specific function or functions that are problematic ( and target a very specific question also if still needed.)

Upvotes: 1

Related Questions