Open andrewchambers opened 4 years ago
To clarify, LIBRARY_PATH
here is referring to LD_LIBRARY_PATH
, right?
No, https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html LIBRARY_PATH is listed here.
Thanks!
So glad I asked :)
I can try these out on some of our existing packages to see how that goes.
The docs mentioned start with:
The value of LIBRARY_PATH is a colon-separated list of directories, much like PATH.
I think that part even I can follow :)
When configured as a native compiler, GCC tries the directories thus specified when searching for special linker files, if it cannot find them using GCC_EXEC_PREFIX.
I didn't figure out what "special linker files" meant. Are you interested in this bit? Do you know what "special linker files" means by any chance? I looked above on the same page at the GCC_EXEC_PREFIX
docs and I guess may be things like crt0.o
are being referred to but don't feel confident in that reading.
I think I can understand if there is interest in the second part:
Linking using GCC also uses these directories when searching for ordinary libraries for the -l option (but directories specified with -L come first).
The overall sense for me is that if this could work, it would be nice for this last bit involved in linking.
What I'm wary of are these other behaviors that might come about. One example is the description that starts:
In addition, the prefix is used in an unusual way
May be it's not worth being concerned about?
CPATH Also looks useful for us.
It looks like CPATH
affects all programming languages while C_INCLUDE_PATH
affects C only (and analogously for the other two mentioned CPLUS_INCLUDE_PATH
and OBJC_INCLUDE_PATH
).
Regarding LD_RUN_PATH
, apparently the gold linker doesn't support it (yet?), though there appears to be a patch:
Are we using gold?
No, I don't think we are using gold.
I tried to use LD_RUN_PATH
in a draft of curl.hpkg but the straight-forward approach I tried did not succeed.
I think it may be related to this:
If -rpath is not used when linking an ELF executable, the contents of the environment variable LD_RUN_PATH will be used if it is defined.
via: https://sourceware.org/binutils/docs/ld/Options.html
I looked at the compilation output and noted some instances of -rpath
that I don't think I was responsible for. It may be that to get it to work for this particular case, there is something that can be tweaked -- I didn't find anything in configure --help
output that looked relevant though.
Here's what I tried: https://gist.github.com/sogaiu/1e258a014a2ed414f07da4e7b4618dae#file-curl-hpkg-L44_L45
FWIW, I've tried using LD_RUN_PATH
on some of the xorg packages and so far it seems to be working ok.
Perhaps this could work out with the propagating env vars idea from: https://github.com/andrewchambers/hpkgs/issues/93
I was able to get the curl package to heed LD_RUN_PATH
by patching the generated libtool
script like this:
(rewrite "libtool"
|(string/replace "hardcode_libdir_flag_spec=\"\\$wl-rpath \\$wl\\$libdir\""
"hardcode_libdir_flag_spec=\"\""
$))
This yields a curl executable and associated library that work.
However, the .so for curl needs to be able to find zlib and openssl bits, but the curl binary does not (it needs to be able to find libcurl.so instead). That is, they require different RUNPATH
values which will not be satisfied exactly in each case by specifying a single value for LD_RUN_PATH
.
I suppose I can shape the results using patchelf...
For reference, the following seemed to work well for "pruning" RUNPATH
values for curl and libcurl.so:
(sh/$ patchelf --shrink-rpath
(string (dyn :pkg-out) "/lib/libcurl.so"))
(sh/$ patchelf --shrink-rpath
(string (dyn :pkg-out) "/bin/curl"))
Its a question if this is an improvment or not I guess.
Yes, I think it's kind of hard to say at this point so I'll continue to experiment with other packages.
I'm not sure how well this will work, but if the toolchain plays along this might be a better way of doing things.