Attempt to use LD_RUN_PATH and LIBRARY_PATH instead of -Wl,rpath= and -L

[andrewchambers]

I'm not sure how well this will work, but if the toolchain plays along this might be a better way of doing things.

[sogaiu]

To clarify, LIBRARY_PATH here is referring to LD_LIBRARY_PATH, right?

[andrewchambers]

No, https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html LIBRARY_PATH is listed here.

[sogaiu]

Thanks!

So glad I asked :)

I can try these out on some of our existing packages to see how that goes.

[sogaiu]

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?

[andrewchambers]

CPATH Also looks useful for us.

[sogaiu]

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).

[sogaiu]

Regarding LD_RUN_PATH, apparently the gold linker doesn't support it (yet?), though there appears to be a patch:

• https://sourceware.org/bugzilla/show_bug.cgi?id=13764
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660813

[andrewchambers]

Are we using gold?

[sogaiu]

No, I don't think we are using gold.

[sogaiu]

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

[sogaiu]

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

[sogaiu]

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...

[sogaiu]

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"))

[andrewchambers]

Its a question if this is an improvment or not I guess.

[sogaiu]

Yes, I think it's kind of hard to say at this point so I'll continue to experiment with other packages.