Hello Mike, Bob, * Bob Proulx wrote on Tue, Sep 26, 2006 at 04:41:19AM CEST: > > 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 feel obliged to point out that the order of priority here is system dependent. On most GNU/Linux distributions, it works as you say; on Gentoo, LD_LIBRARY_PATH overrides the hardcoded path (because they patch their ld to set both DT_RPATH and DT_RUNPATH); FWIW, on other systems it may depend on linker flags (HP-UX/PA, for example), the rpath always wins (e.g., IRIX) or never wins (e.g., NetBSD). > (I do not like rpath because it freezes the configuration into an > inflexible state.) But also it allows programs to work without having the user to set an ever-longer LD_LIBRARY_PATH. It's a two-edged sword. > Mike Melanson wrote: > > 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. Yes. Linking libstdc++ statically into your plugin won't do what you like, if the libstdc++ used by other parts of the program you run is not binary compatible. It simply won't work, and I think http://www.trilithium.com/johan/2005/06/static-libstdc/ summarizes that nicely. You may also want to note that linking libstdc++ statically into a plugin won't necessarily do what you want, i.e., use its symbols rather than the ones from a system's libstdc++ that has been loaded earlier because the program (or some library it depends upon) uses that. The reverse may also happen (some plugin dlopened later may just happen to use some symbols of your copy rather than the installed libstdc++ ones'). This is how ELF linking works. Do you use something like symbolic linkage for symbols inside your module (to prevent the first problem), and hide all the libstdc++ symbols that end up in your module (to prevent the second problem)? Below's a small recipe to show the first of the two issues. If you're seeing weird bugs, or browsers that use your plugin see them with other bugs, you may want to read this again. Note I am not suggesting that you go this route (not at all), because closing the potential incompatibility between your plugin and the libstdc++ symbols it uses, just opens up the potential incompatibility between the libstdc++ symbols you use, and the ones the rest of the program uses. I would think building two different plugins, one for version 5 and one for version 6 is a safer bet. And of course, allowing users and distributions to build from source is a much safer bet. Cheers, Ralf cat >a.c <<EOF double sin(double x) { return 0.0; } EOF cat >b.c <<EOF extern double sin(double); double b() { return sin(1.0);} EOF cat >m.c <<EOF #include <stdlib.h> #include <stdio.h> #include <dlfcn.h> #include <math.h> int main(int argc, char **argv) { void *handle; double (*ptr_b)(void); char *error; handle = dlopen ("libb.so", RTLD_LAZY); if (!handle) { fprintf (stderr, "%s\n", dlerror()); exit(1); } dlerror(); /* Clear any existing error */ *(void **) (&ptr_b) = dlsym(handle, "b"); if ((error = dlerror()) != NULL) { fprintf (stderr, "%s\n", error); exit(1); } printf ("%f\n", (*ptr_b)()); printf ("%f\n", sin(1.0)); dlclose(handle); return 0; } EOF gcc -fPIC -c a.c ar cru liba.a a.o gcc -fPIC -c b.c gcc -shared -o libb.so b.o liba.a gcc -c m.c gcc -o m m.o -ldl -lm LD_LIBRARY_PATH=. ./m # then try adding -Wl,-Bsymbolic to the link creating libb.so