Bug 2158172 - clang sets uneeded RUNPATH when enabling openmp
Summary: clang sets uneeded RUNPATH when enabling openmp
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: clang
Version: 37
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tom Stellard
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-01-04 13:20 UTC by Andreas Schneider
Modified: 2023-12-07 11:08 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2023-12-07 11:08:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Andreas Schneider 2023-01-04 13:20:51 UTC
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

Comment 1 Nikita Popov 2023-01-04 13:47:27 UTC
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.

Comment 2 Andreas Schneider 2023-01-04 14:17:38 UTC
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.

Comment 3 Nikita Popov 2023-01-04 14:57:31 UTC
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.

Comment 4 Andreas Schneider 2023-01-04 15:34:15 UTC
That would be great! Thanks for looking into this.

Comment 5 Nikita Popov 2023-01-05 17:12:51 UTC
Tom pointed out that there's some existing discussion of this issue at https://reviews.llvm.org/D118493#3398189.

Comment 6 Andreas Schneider 2023-03-14 10:07:56 UTC
Looks like this got reverted, see https://reviews.llvm.org/rG555b572e3f407ac48b5f30fc06760cc4d0549977

Comment 7 Tom Stellard 2023-10-13 21:21:36 UTC
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?

Comment 8 Aoife Moloney 2023-11-23 00:53:59 UTC
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.

Comment 9 Aoife Moloney 2023-12-07 11:08:44 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.