Re: [Chicken-users] Incorrectly linked binaries with chicken-install -deploy

[Thomas Chust]

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.