Re: Forcing static link of libstdc++

[Bob Proulx]

Mike Melanson wrote:
> Sounds like a useful possible solution. However, what if the primary 
> functionality actually resides in a shared library itself?

As shown by ldd on the shared library?  Those will be loaded using
LD_LIBRARY_PATH so in that case you don't need the complicated wrapper
for libc using ld.so but just the simple one that only sets the
environment variable for the dynamic loader to follow.

Unless the shared library is using rpath.  In which case it will use
the compiled in path first and only if that fails will it fall back to
using LD_LIBRARY_PATH and if that fails fall back to using whatever is
configured for the system in /etc/ld.so.conf.  (I do not like rpath
because it freezes the configuration into an inflexible state.)

> This is a proprietary plugin that another program is expected to
> load and call. Is there some sort of wrapper trick for that, or is
> that up to the communication between the app and the plugin?

Everything depends upon how the application is loading the shared
library.  If it done by the linker then ld.so will load it and
LD_LIBRARY_PATH should work to find it.  If the application is
dynamically loading a specific file from the filesystem then you are
stuck with whatever the application allows you to adjust.

All of this is assuming that I did not get some of this wrong.

Bob