2

I have a C++ 3rd party library in source code. It is self-contained and does not refer to any other library. It uses C++14, hence it requires a modern gcc compiler.

I want to use some of its functions in a software application compiled for RHEL5 with an old version of gcc, which does not understand modern C++.

To solve the problem I am creating with gcc 7.2 a shared library (.so) which exposes a plain and simple C api. I would like the so file to be self contained hence I use the link line:

g++ -shared -static-libstdc++ -static-libgcc

I am not using the option -static, as I could not get it to work, despite I used -fPIC when generating my object files. Probably because the static libraries for libstdc++ might be compiled without fPIC. So ldd shows that my so has some dependencies on libc and libm. objectdump -T shows that most of these dependencies are compatible with RHEL5, because they require a version of GLIBC older than 2.5. However there is one dependency on memcpy which requires GLIBC 2.14. This does not come directly from my source code, but probably from libstdc++ or libgcc, which are being statically linked.

Is there any way I can provide my own implementation of memcpy and tell the linker to use that everywhere, instead of the one from glibc?

yugr
  • 19,769
  • 3
  • 51
  • 96
Fabio
  • 2,105
  • 16
  • 26
  • 1
    Try to search for "gcc mocking call", something like https://stackoverflow.com/questions/13961774/gnu-gcc-ld-wrapping-a-call-to-symbol-with-caller-and-callee-defined-in-the-sam – Jean-Baptiste Yunès Dec 15 '17 at 09:51
  • Found some good suggestions here. https://stackoverflow.com/questions/8823267/linking-against-older-symbol-version-in-a-so-file/8823419#8823419 I just need to be careful with the fact that in 2.14 memcpy became a GNU_IFUNC function, therefore my local copy needs to have a consistent type, otherwise I may have a problem with libstdc++ and libgcc. – Fabio Dec 15 '17 at 16:10

0 Answers0