Description of problem: This feature might be useful if libomp is in a non standard search path. but in we are a LSB and in this case the library is in the default search path. We found this behavior while debugging the fedora builds of [vkdt][0]. There was one library which check-rpath scripts complained that it has a RUNPATH set to /usr/lib64. [ 158s] * [ 158s] * WARNING: 'check-rpaths' detected a broken RPATH OR RUNPATH and will cause [ 158s] * 'rpmbuild' to fail. To ignore these errors, you can set the [ 158s] * '$QA_RPATHS' environment variable which is a bitmask allowing the [ 158s] * values below. The current value of QA_RPATHS is 0x0000. [ 158s] * [ 158s] * 0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor [ 158s] * issue but are introducing redundant searchpaths without [ 158s] * providing a benefit. They can also cause errors in multilib [ 158s] * environments. [ 158s] * 0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute [ 158s] * nor relative filenames and can therefore be a SECURITY risk [ 158s] * 0x0004 ... insecure RPATHs; these are relative RPATHs which are a [ 158s] * SECURITY risk [ 158s] * 0x0008 ... the special '$ORIGIN' RPATHs are appearing after other [ 158s] * RPATHs; this is just a minor issue but usually unwanted [ 158s] * 0x0010 ... the RPATH is empty; there is no reason for such RPATHs [ 158s] * and they cause unneeded work while loading libraries [ 158s] * 0x0020 ... an RPATH references '..' of an absolute path; this will break [ 158s] * the functionality when the path before '..' is a symlink [ 158s] * [ 158s] * [ 158s] * Examples: [ 158s] * - to ignore standard and empty RPATHs, execute 'rpmbuild' like [ 158s] * $ QA_RPATHS=$(( 0x0001|0x0010 )) rpmbuild my-package.src.rpm [ 158s] * - to check existing files, set $RPM_BUILD_ROOT and execute check-rpaths like [ 158s] * $ RPM_BUILD_ROOT=<top-dir> /usr/lib/rpm/check-rpaths [ 158s] * [ 158s] ******************************************************************************* [ 158s] ERROR 0001: file '/usr/libexec/vkdt/modules/i-mlv/libi-mlv.so' contains a standard runpath '/usr/lib64' in [/usr/lib64] [ 158s] error: Bad exit status from /var/tmp/rpm-tmp.tfgTqm (%install) Steps to Reproduce: // cat openmp-reproducer.c #include <stdio.h> #include <omp.h> int main(int argc, char** argv){ #pragma omp parallel { printf("Hello from process: %d\n", omp_get_thread_num()); } return 0; } clang --verbose openmp-reproducer.c -fopenmp -shared -o openmp-reproducer clang version 15.0.6 (Fedora 15.0.6-2.fc37) Target: x86_64-redhat-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/12 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/12 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 "/usr/bin/clang-15" -cc1 -triple x86_64-redhat-linux-gnu -emit-obj -mrelax-all --mrelax-relocations -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name openmp-reproducer.c -mrelocation-model static -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -mllvm -treat-scalable-fixed-error-as-warning -debugger-tuning=gdb -v -fcoverage-compilation-dir=/home/asn -resource-dir /usr/lib64/clang/15.0.6 -internal-isystem /usr/lib64/clang/15.0.6/include -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../x86_64-redhat-linux/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir=/home/asn -ferror-limit 19 -fopenmp -fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/openmp-reproducer-7c1b89.o -x c openmp-reproducer.c clang -cc1 version 15.0.6 based upon LLVM 15.0.6 default target x86_64-redhat-linux-gnu ignoring nonexistent directory "/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../x86_64-redhat-linux/include" ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/lib64/clang/15.0.6/include /usr/local/include /usr/include End of search list. "/usr/bin/ld" --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -shared -o openmp-reproducer /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../lib64/crti.o /usr/bin/../lib/gcc/x86_64-redhat-linux/12/crtbeginS.o -L/usr/bin/../lib/gcc/x86_64-redhat-linux/12 -L/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/lib -L/usr/lib /tmp/openmp-reproducer-7c1b89.o -lomp -rpath /usr/lib64 -L/usr/lib64 -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/bin/../lib/gcc/x86_64-redhat-linux/12/crtendS.o /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../lib64/crtn.o Actual results: objdump -x openmp-reproducer | grep RUNPATH RUNPATH /usr/lib64 Expected results: objdump -x openmp-reproducer | grep RUNPATH Additional info: [0]: https://build.opensuse.org/package/show/graphics:darktable:master/vkdt
We pass -fno-openmp-implicit-rpath via redhat-rpm-config here: https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_74 So if you are building in a fedora rpm environment, and have "%global toolchain clang" set, the rpath should be omitted. Is this not the case? If this is about builds outside an rpm environment (i.e. as a user of fedora, not a packager), then I'm not sure it would make sense to deviate from the clang default.
Why should it set RUNPATH to /usr/lib64, the "default" search path by default, even if I do not create an RPM Package. This really doesn't make sense.
Hm yeah, adding /usr/lib64 in particular to the rpath seems pretty weird. Looks like this is handled here: https://github.com/llvm/llvm-project/blob/23ce9383ca07260120df55200110373c11a5d2ff/clang/lib/Driver/ToolChains/CommonArgs.cpp#L794 TC.getDriver().Dir is the directory of the clang executable, so /usr/bin, and then the resulting path is /usr/lib64. TBH I'm not sure why clang is doing this. This should usually end up being a system libdir, that doesn't seem Fedora specific. Possibly we can get this default changed upstream.
That would be great! Thanks for looking into this.
Tom pointed out that there's some existing discussion of this issue at https://reviews.llvm.org/D118493#3398189.
Looks like this got reverted, see https://reviews.llvm.org/rG555b572e3f407ac48b5f30fc06760cc4d0549977
This has been fixed upstream in Clang 17.0.x, which will be shipped in Fedora 39. Do we want to update Clang 15 / F37 and Clang 16 / F38 to match the Clang 17 /F39 behavior or just leave it as is?
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 37 entered end-of-life (EOL) status on 2023-12-05. Fedora Linux 37 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.