On 2015-08-14 04:43, Ryan Senior wrote: > Does anyone have stand-alone application deployments working via > chicken-install? I'm running into an issue where the binaries for my > executables are in place, but they are linked to the system libchicken. > [...]
Hello, the libchicken.so.* is a dynamic library and dynamic libraries are linked, well, dynamically ;-) This means, which library is actually loaded when the dependent program or library is loaded can vary depending on several parameters. If you wanted to play safe, you could include a -Wl,-rpath,'$ORIGIN' in CSC_OPTIONS while running chicken-install or even put "-L" "-Wl,-rpath,$ORIGIN" in the compiler options in your build script. You should also ensure that the libchicken.so.* is actually present alongside your compiled binaries, of course, but that can be done by simply copying it there. This may be necessary, because the dynamic linker of Linux performs a rather convoluted search for dynamic libraries in a number of directories, picking the first one that it finds: (1) The linker examines the executable (and already loaded libraries) and looks for a DT_RPATH ELF section attribute. If that attribute is present and no DT_RUNPATH attribute is also present, the linker will search the directories specified in that attribute. (2) The linker examines the LD_LIBRARY_PATH environment variable. Unless the executable in question is setuid or setgid, all directories specified in that variable are searched. (3) The linker examines the executable (and already loaded libraries) and looks for the DT_RUNPATH ELF section attribute. If this attribute is present, the linker searches the directories specified there. (4) Unless the executable in question was linked with some magic flags to disable default library locations, the linker now consults a system wide cache (/etc/ld.so.cache) and eventually may resort to searching some core system default directories like /lib for the library. When you call ldd on a binary, that binary is actually loaded, its initialization code, if any, is executed, and the dynamic linker is asked to report all the dependencies that it loaded, too. Thus what ldd reports may, for example, be different from what is actually happening at the runtime of your program, if you apply ldd to a dynamic library without a DT_RUNPATH attribute but link your actual host program with a DT_RUNPATH attribute. I suspect that is precisely what happens, because, if I'm not mistaken, csc -deploy links the executable with a -rpath linker flag (or something equivalent) while chicken-install doesn't do that. To see what DT_RPATH and DT_RUNPATH attributes are set in your libraries and executables, or to modify them, you can use the utility program chrpath. I hope that helps :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
