clang's build environment does not respect `LD_RUN_PATH`

[llvmbot]

Bugzilla Link	18601
Version	unspecified
OS	Linux
Reporter	LLVM Bugzilla Contributor

Extended Description

I asked our university's IT staff to install a current version of clang/clang++ on one of our machines. He installed 3.4, but was forced to include this snarky wrapper for using it (he told me I could include the snark! Please don't shoot the messenger!):

#!/bin/bash

# clang's build environment does not obey LD_RUN_PATH, so have to use
# this workaround at run time. D41S, argh!
LD_LIBRARY_PATH=/usr/sup/lib64:/usr/sup/lib:/lib64:/usr/lib64:/lib:/usr/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH

# At least clang itself obeys LD_RUN_PATH, set it to prevent screwy errors
# later.
LD_RUN_PATH=/usr/sup/lib64:/usr/sup/lib:/lib64:/usr/lib64:/lib:/usr/lib:$LD_LIBRARY_PATH export LD_RUN_PATH

# clang does not retain the environment it was built under, so have to use
# this workaround at run time.  D41S, argh!
CPATH=/usr/sup/include:/usr/sup/include/c++/4.8.0:CPATH export CPATH
LIBRARY_PATH=/usr/sup/lib64:/usr/sup/lib:/lib64:/usr/lib64:/lib:/usr/lib:$LIBRARY_PATH export LIBRARY_PATH

# Now that we've worked around most of the stupid, invoke clang++ with
# the invocation that takes care of the rest of the stupid.
/usr/sup/llvm-3.4/bin/clang++ -I/usr/sup/include -I/usr/sup/include/c++/4.8.0 $*

Other possibly relevant information:

$ which clang++
/usr/sup/bin/clang++

$ clang++ --version
clang version 3.4 (tags/RELEASE_34/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.5 (Santiago)

Our IT staff puts a lot of stuff in the /usr/sup/bin directory, and it seems to me that this is what is causing the headache.

If this isn't a bug, I'd like to pass on to the IT guy what could be done to remedy this without the wrapper.

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: None (llvmbot)

| | | | --- | --- | | Bugzilla Link | [18601](https://llvm.org/bz18601) | | Version | unspecified | | OS | Linux | | Reporter | LLVM Bugzilla Contributor | ## Extended Description I asked our university's IT staff to install a current version of clang/clang++ on one of our machines. He installed 3.4, but was forced to include this snarky wrapper for using it (he told me I could include the snark! Please don't shoot the messenger!): ```bash #!/bin/bash # clang's build environment does not obey LD_RUN_PATH, so have to use # this workaround at run time. D41S, argh! LD_LIBRARY_PATH=/usr/sup/lib64:/usr/sup/lib:/lib64:/usr/lib64:/lib:/usr/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH # At least clang itself obeys LD_RUN_PATH, set it to prevent screwy errors # later. LD_RUN_PATH=/usr/sup/lib64:/usr/sup/lib:/lib64:/usr/lib64:/lib:/usr/lib:$LD_LIBRARY_PATH export LD_RUN_PATH # clang does not retain the environment it was built under, so have to use # this workaround at run time. D41S, argh! CPATH=/usr/sup/include:/usr/sup/include/c++/4.8.0:CPATH export CPATH LIBRARY_PATH=/usr/sup/lib64:/usr/sup/lib:/lib64:/usr/lib64:/lib:/usr/lib:$LIBRARY_PATH export LIBRARY_PATH # Now that we've worked around most of the stupid, invoke clang++ with # the invocation that takes care of the rest of the stupid. /usr/sup/llvm-3.4/bin/clang++ -I/usr/sup/include -I/usr/sup/include/c++/4.8.0 $* ``` Other possibly relevant information: ```console $ which clang++ /usr/sup/bin/clang++ $ clang++ --version clang version 3.4 (tags/RELEASE_34/final) Target: x86_64-unknown-linux-gnu Thread model: posix $ cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) ``` Our IT staff puts a lot of stuff in the `/usr/sup/bin` directory, and it seems to me that this is what is causing the headache. If this isn't a bug, I'd like to pass on to the IT guy what could be done to remedy this without the wrapper.