0

According to the GCC ABI Policy and Guidelines page I get that they try to maintain forward compatibility but I wonder to what extend this is true or if I'm missing something.

I am currently trying to run C++ software which was built on red hat 5 using gcc 4.1.2 / libstdc++ 6.0.8 on a CentOS 7 with libstdc++ 6.0.19.

I am experiencing weird behavior such as random crashes (might work for a while, then crash systematically for 30 minutes, then work again ...) or memory shooting up to use all 64GB of the server (never seen this issue before).

I seem to have fixed the issue with one of the miss-behaving programs by statically linking libgcc and libstdc++. A few hours have passed with no crash. I am thinking of playing with LD_LIBRARY_PATH and shipping the libraries with the executables.

But applying the same kind of solutions to the whole system will be quite time consuming, so I would appreciate if someone can tell me if I'm on the right track.

-- edit --

I forgot to mention, some libs are linked statically to libstdc++, some dynamically so I have situations like:

program_a -(dyn link)-> libstdc++
         |-(dyn link)-> lib_b -(static link)-> libstdc++
                             |-(dyn link)----> lib_c -(dyn link)-> libstdc++

So here I have one libstdc++ being the system one, the other one being the compiler's one.

foke
  • 1,339
  • 2
  • 12
  • 20
  • 1
    Forward compatibility doesn't mean that the behavior with buggy code will be the same, it's only intended for conforming code. It's likely that you have bugs causing undefined behavior, and the result of this has changed. – Barmar Jun 23 '20 at 18:39
  • So you need to debug the reason for the crashes and fix those problems. They were always there, you just didn't notice before because the programs didn't crash. – Barmar Jun 23 '20 at 18:40
  • If you have a crash and you're wondering whether it's a bug in your code or in the system libraries, it's 99% likely to be your bug. – Barmar Jun 23 '20 at 18:41
  • The difference may also not even be due to the compiler or library version, it is possible that the different kernels (version, build options, configuration) make the issues more likely to surface in one OS than the other, but as Barmar points out they are very probably just problems that were latent before. Maybe you can check with Valgrind if anything comes up. – jdehesa Jun 23 '20 at 18:57
  • @Barmar Good point, the issue is that it's a big code base, pretty complicated, developed over years (decades...) by many people and now I'm the one guy alone who has to make it work on CentoOs :) For me debugging all this seems unfeasable so if I can find a solution like shipping the old libs and making sure the software uses it and be done with it I would prefer! – foke Jun 24 '20 at 08:22
  • In that case the usual solution is static linking. It should work as long as the problem isn't with OS compatibility. – Barmar Jun 24 '20 at 14:09

0 Answers0