Is there a way to set the elf NEEDED field at link time?

Question

Given a executable such that:

>objdump -x someprog | grep c++
NEEDED               libstdc++.so.6

I want to change the requirement to the fu

Answer 1

I think I have answered my problem though not the question I actually asked.

RPATH is searched before LD_LIBRARY_PATH. The reason /usr/lib64/libstdc++.so.6 is being picked up rather than libstdc++.so.6.0.22 is that there is no symbolic link from /where/i/installed/libstdc++.so.6 to /where/i/installed/libstdc++.so.6.0.22

So the rule is follow the standards for your platform (where they are sensible). In this case: Whenever you install a shared library install the expected links as well.

I think the actual question I asked is still interesting technically so I will still accept a better answer to that if anyone has one (even years later).

Answer 2

This will not work because libstdc++.so.6.0.22 will export the same symbols as the system libstdc++, and you will end up with a wild mix between the two libraries (assuming you indeed change the soname of the newer libstdc++ version).

You should either link the whole of libstdc++ statically (this may require a static PIC variant of the library) and not export any symbols (probably with a linker version script), or link only the new symbols statically.

The second approach seems to be the best option at present: It allows you to use most new language features, but you have still a large degree of interoperability with the rest of the system (especially if you configure GCC with --with-default-libstdcxx-abi=gcc4-compatible), and you don't have to install any additional shared objects for deployment. This is how the Developer Toolset software collection provides newer versions of GCC (and I believe the SUSE Linux Toolchain Module, too). Full static linking causes problems if C++ objects are passed across shared object boundaries (which includes exception handling), and this kind of selective static linking avoids many of these these problems.