search

andrewchambers / hpkgs

A package repository for hermes
45 stars 3 forks source link

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

Open andrewchambers opened 4 years ago

andrewchambers commented 4 years ago

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 commented 4 years ago

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

andrewchambers commented 4 years ago

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

sogaiu commented 4 years ago

Thanks!

So glad I asked :)

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

sogaiu commented 4 years ago

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 commented 4 years ago

CPATH Also looks useful for us.

sogaiu commented 4 years ago

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 commented 4 years ago

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

andrewchambers commented 4 years ago

Are we using gold?

sogaiu commented 4 years ago

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

sogaiu commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

sogaiu commented 4 years ago

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