segfaults during cleanup

i’ve got an application build with boost-1.37 (among other libraries). it appears to run, but dies when the dtors are called.

Is there a problem with the order of the shared libraries? i see some libc and libpgc which could conflict?

host > app
app runs nicely and gives results equivalent to intel and g++
============= TEST COMPLETE ===========

C++ runtime abort: terminate() called by the exception handling mechanism
host> ldd /local/mcatk/users/sdnolen/workspace/obj/pgi-opt/src/Interface/fi_test/Interface_fi_tester_run => /local/mcatk/packages/lib/ (0x0000002a95557000) => /local/mcatk/packages/lib/ (0x0000002a956c7000) => /local/mcatk/packages/lib/ (0x0000002a9583e000) => /local/mcatk/packages/lib/ (0x0000002a95aaf000) => /local/mcatk/packages/lib/ (0x0000002a95d94000) => /local/mcatk/packages/lib/ (0x0000002a95ea0000) => /local/mcatk/packages/lib/ (0x0000002a96374000) => /local/mcatk/packages/src/tbb-2.0.17/build/linux_em64t_pgi_cc4.3.3_libc2.3.4_kernel2.6.9_release/ (0x0000002a9649a000) => /lib64/tls/ (0x0000003f9d100000) => /local/mcatk/packages/lib/ (0x0000002a965ec000) => /local/mcatk/packages/lib/ (0x0000002a96707000) => /local/mcatk/packages/lib/ (0x0000002a968b0000) => /local/mcatk/packages/lib/ (0x0000002a969f8000) => /lib64/ (0x0000003f9cb00000) => /lib64/ (0x0000003fa4800000) => /lib64/ (0x0000003f9ef00000) => /lib64/tls/ (0x0000003f9c900000) => /usr/lib64/ (0x0000003f9c400000) => /opt/local/vendor/pgi-10.1/10.1/share_objects/lib64/ (0x0000002a96b6f000) => /opt/local/vendor/pgi-10.1/linux86-64/10.1/libso/ (0x0000002a96c71000) => /opt/local/vendor/pgi-10.1/linux86-64/10.1/libso/ (0x0000002a96edb000) => /opt/local/vendor/pgi-10.1/linux86-64/10.1/libso/ (0x0000002a96ff3000) => /lib64/tls/ (0x0000003f9c600000) => /lib64/tls/ (0x0000003fa1000000)
/lib64/ (0x0000003f9c200000) => /local/mcatk/packages/lib/…/lib64/ (0x0000002a97149000) => /local/mcatk/packages/lib/…/lib64/ (0x0000002a97354000)

the only library not build specifically with PGI was the openmpi one, but we are only using the c-interface from this (or at least boost is)


I will try to answer what I can.

We have been getting better at boost, but have not built it all,
and I am not sure what runs.

wrt libc and libpgc, libpgc calls libc routines. We found several years ago
that libc routines would change the number, order, and type of arguments
passed to them from release to release. We created libpgc to have a consistent
interface. For each linux system we installed, a version of libpgc was created
to handle the libc version on that lionux system.

Our runtime libs call routines from the shared, which is
installed to compliment the version of resident. In theory,
you can compile on machine A with version A and
run it on machine B with its version B, as long as you install that was created for version B on platform B.

Today, has a consistent interface across most linux systems, and
so is the same for all targets. Should differences crop up again,
we may need multiple files again.