search

Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

Compiler-RT contains math functions but doesn't use -lm when linking programs #28651

Open Quuxplusone opened 8 years ago

Quuxplusone commented 8 years ago
Bugzilla Link PR28652
Status NEW
Importance P normal
Reported by Armin K. (krejzi@email.com)
Reported on 2016-07-21 17:57:27 -0700
Last modified on 2018-07-16 10:04:31 -0700
Version 3.9
Hardware PC Linux
CC chris.bieneman@gmail.com, chris.bieneman@me.com, hans@chromium.org, llvm-bugs@lists.llvm.org, rupprecht@google.com
Fixed by commit(s)
Attachments file_28652.txt (502 bytes, text/plain)
Blocks
Blocked by
See also 
When using Compiler-RT as the default runtime on Linux x86_64 and trying to
build another clang with the clang that uses Compiler-RT as the default
runtime, I get the following failure when building openmp part:

Linking C shared library ../../../../lib/libomp.so
cd /sources/llvm-build/projects/openmp/runtime/src && /usr/bin/cmake -E
cmake_link_script CMakeFiles/omp.dir/link.txt --verbose=1
/tools/bin/clang  -fPIC -march=skylake -fomit-frame-pointer -O2 -pipe -fPIC -
Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -
pedantic -Wno-long-long -Wcovered-switch-default -Wdelete-non-virtual-dtor -
Werror=date-time -ffunction-sections -fdata-sections -O3 -DNDEBUG -Wl,--warn-
shared-textrel -Wl,--as-needed -Wl,--version-
script=/sources/llvm/projects/openmp/runtime/src/exports_so.txt -static-libgcc -
Wl,-z,noexecstack -Wl,-fini=__kmp_internal_end_fini  -Wl,-z,defs -shared -Wl,-
soname,libomp.so -o ../../../../lib/libomp.so CMakeFiles/omp.dir/kmp_alloc.c.o
CMakeFiles/omp.dir/kmp_atomic.c.o CMakeFiles/omp.dir/kmp_csupport.c.o
CMakeFiles/omp.dir/kmp_debug.c.o CMakeFiles/omp.dir/kmp_itt.c.o
CMakeFiles/omp.dir/kmp_environment.c.o CMakeFiles/omp.dir/kmp_error.c.o
CMakeFiles/omp.dir/kmp_global.c.o CMakeFiles/omp.dir/kmp_i18n.c.o
CMakeFiles/omp.dir/kmp_io.c.o CMakeFiles/omp.dir/kmp_runtime.c.o
CMakeFiles/omp.dir/kmp_settings.c.o CMakeFiles/omp.dir/kmp_str.c.o
CMakeFiles/omp.dir/kmp_tasking.c.o CMakeFiles/omp.dir/kmp_taskq.c.o
CMakeFiles/omp.dir/kmp_threadprivate.c.o CMakeFiles/omp.dir/kmp_utility.c.o
CMakeFiles/omp.dir/z_Linux_util.c.o CMakeFiles/omp.dir/kmp_gsupport.c.o
CMakeFiles/omp.dir/thirdparty/ittnotify/ittnotify_static.c.o
CMakeFiles/omp.dir/kmp_ftn_cdecl.c.o CMakeFiles/omp.dir/kmp_ftn_extra.c.o
CMakeFiles/omp.dir/kmp_version.c.o CMakeFiles/omp.dir/kmp_barrier.cpp.o
CMakeFiles/omp.dir/kmp_wait_release.cpp.o CMakeFiles/omp.dir/kmp_affinity.cpp.o
CMakeFiles/omp.dir/kmp_dispatch.cpp.o CMakeFiles/omp.dir/kmp_lock.cpp.o
CMakeFiles/omp.dir/kmp_sched.cpp.o CMakeFiles/omp.dir/kmp_taskdeps.cpp.o
CMakeFiles/omp.dir/kmp_cancel.cpp.o CMakeFiles/omp.dir/z_Linux_asm.s.o -
lpthread -lm -ldl -Wl,-rpath,"\$ORIGIN/../lib"
clang-3.9: warning: argument unused during compilation: '-static-libgcc'
/tools/bin/../lib/clang/3.9.0/lib/linux/libclang_rt.builtins-
x86_64.a(divdc3.c.o): In function `__divdc3':
divdc3.c:(.text.__divdc3+0x35): undefined reference to `fmax'
divdc3.c:(.text.__divdc3+0x3a): undefined reference to `logb'
/tools/bin/../lib/clang/3.9.0/lib/linux/libclang_rt.builtins-
x86_64.a(divsc3.c.o): In function `__divsc3':
divsc3.c:(.text.__divsc3+0x32): undefined reference to `fmaxf'
divsc3.c:(.text.__divsc3+0x37): undefined reference to `logbf'
/tools/bin/../lib/clang/3.9.0/lib/linux/libclang_rt.builtins-
x86_64.a(divxc3.c.o): In function `__divxc3':
divxc3.c:(.text.__divxc3+0x22): undefined reference to `fmaxl'
divxc3.c:(.text.__divxc3+0x2c): undefined reference to `logbl'
clang-3.9: error: linker command failed with exit code 1 (use -v to see
invocation)
make[2]: *** [projects/openmp/runtime/src/CMakeFiles/omp.dir/build.make:901:
lib/libomp.so] Error 1

Note, however, that there's -lm included on the command line (I manually added
it with cmake parameter), but it still isn't being picked up. Running the
command manually, and using -v, gives the following linker invocation command:

 "/tools/bin/ld" --eh-frame-hdr -m elf_x86_64 -shared -o ../../../../lib/libomp.so /tools/bin/../lib64/crti.o /tools/bin/../lib/clang/3.9.0/64/crtbeginS.o -L/tools/bin/../lib/clang/3.9.0/64 -L/tools/bin/../lib64 -L/lib/../lib64 -L/tools/bin/../lib -L/lib -L/usr/lib --warn-shared-textrel --as-needed --version-script=/sources/llvm/projects/openmp/runtime/src/exports_so.txt -z noexecstack -fini=__kmp_internal_end_fini -z defs -soname libomp.so CMakeFiles/omp.dir/kmp_alloc.c.o CMakeFiles/omp.dir/kmp_atomic.c.o CMakeFiles/omp.dir/kmp_csupport.c.o CMakeFiles/omp.dir/kmp_debug.c.o CMakeFiles/omp.dir/kmp_itt.c.o CMakeFiles/omp.dir/kmp_environment.c.o CMakeFiles/omp.dir/kmp_error.c.o CMakeFiles/omp.dir/kmp_global.c.o CMakeFiles/omp.dir/kmp_i18n.c.o CMakeFiles/omp.dir/kmp_io.c.o CMakeFiles/omp.dir/kmp_runtime.c.o CMakeFiles/omp.dir/kmp_settings.c.o CMakeFiles/omp.dir/kmp_str.c.o CMakeFiles/omp.dir/kmp_tasking.c.o CMakeFiles/omp.dir/kmp_taskq.c.o CMakeFiles/omp.dir/kmp_threadprivate.c.o CMakeFiles/omp.dir/kmp_utility.c.o CMakeFiles/omp.dir/z_Linux_util.c.o CMakeFiles/omp.dir/kmp_gsupport.c.o CMakeFiles/omp.dir/thirdparty/ittnotify/ittnotify_static.c.o CMakeFiles/omp.dir/kmp_ftn_cdecl.c.o CMakeFiles/omp.dir/kmp_ftn_extra.c.o CMakeFiles/omp.dir/kmp_version.c.o CMakeFiles/omp.dir/kmp_barrier.cpp.o CMakeFiles/omp.dir/kmp_wait_release.cpp.o CMakeFiles/omp.dir/kmp_affinity.cpp.o CMakeFiles/omp.dir/kmp_dispatch.cpp.o CMakeFiles/omp.dir/kmp_lock.cpp.o CMakeFiles/omp.dir/kmp_sched.cpp.o CMakeFiles/omp.dir/kmp_taskdeps.cpp.o CMakeFiles/omp.dir/kmp_cancel.cpp.o CMakeFiles/omp.dir/z_Linux_asm.s.o -lpthread -lm -ldl -rpath "\$ORIGIN/../lib" /usr/lib/libmvec_nonshared.a /usr/lib/libmvec.a /usr/lib/libm.a /tools/bin/../lib/clang/3.9.0/lib/linux/libclang_rt.builtins-x86_64.a -lc /tools/bin/../lib/clang/3.9.0/lib/linux/libclang_rt.builtins-x86_64.a /tools/bin/../lib/clang/3.9.0/64/crtendS.o /tools/bin/../lib64/crtn.o

Strange thing is, if I add -lm at the end of the mentioned command (after
/tools/bin/../lib/clang/3.9.0/lib/linux/libclang_rt.builtins-x86_64.a) it gets
linked correctly.

I'm not sure if this is clang or compiler-rt bug, so please reassign as
necessary.
Quuxplusone commented 8 years ago

On a second look at the linker invocation command, it appears to try and link libm statically itself, as seen in the following part:

/usr/lib/libmvec_nonshared.a /usr/lib/libmvec.a /usr/lib/libm.a /tools/bin/../lib/clang/3.9.0/lib/linux/libclang_rt.builtins-x86_64.a -lc

However, for some reason, it isn't being picked up since it's before libclang_rt.builtins-x86_64.a. This might be ld.bfd bug, but then again, it can be solved by swapping

/tools/bin/../lib/clang/3.9.0/lib/linux/libclang_rt.builtins-x86_64.a and

/usr/lib/libmvec_nonshared.a /usr/lib/libmvec.a /usr/lib/libm.a

on the linker command line. Anyways, this might result in increased binary size, so is there a way to build clang runtime as a shared library and link to shared libm (doesn't have to be solved by this bug and doesn't even have to make it to 3.9).

Quuxplusone commented 8 years ago

Perhaps cbieneman can comment? (Also PR28681 might be in the same neighbourhood.)

Armin: is this something that has changed since the 3.8 release? I.e., is it a regression?

Quuxplusone commented 8 years ago

I can't tell, I haven't used compiler-rt with 3.8.

Quuxplusone commented 8 years ago

Where did you get your clang from? If you built it yourself do you happen to know the configuration command line you used?

Quuxplusone commented 8 years ago

Looking into this a bit more. Those symbols are expected to be unresolved in the builtin library, which means the problem is likely either in the driver or the linker.

Quuxplusone commented 8 years ago 
(In reply to comment #4)
> Where did you get your clang from? If you built it yourself do you happen to
> know the configuration command line you used?

https://github.com/elkrejzi/system-management/blob/master/buildscripts/buildllvm#L156

Add -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release to these flags.

clang was patched to explicitly use compiler-rt and some other paths which are
unrelated

https://github.com/elkrejzi/system-management/blob/master/patches/clang-runtime.patch
Quuxplusone commented 8 years ago

Not treating as a 3.9 blocker. I don't think this is a regression.

Quuxplusone commented 8 years ago

I don't think this is actually a bug in our compiler. gnutools::linker::ConstructJob unconditionally adds -lm, to linker invocations.

The out-of-tree patches being used seem to be adding support for a new linux distribution, and it looks like there isn't a proper code path in the clang Tools/Toolchains code.

Someone who actually knows the clang driver would be better suited to diagnose and advise, but I agree with Hans' assessment that this isn't a regression and shouldn't block the release.

Quuxplusone commented 8 years ago 
(In reply to comment #8)
> I don't think this is actually a bug in our compiler.
> gnutools::linker::ConstructJob unconditionally adds -lm, to linker
> invocations.
>

Yes, I can see that. See the original post for linker invocation command.

The issue is that -lm needs to be added *after* compiler-rt libraries for it to
be picked up correctly. Why? No idea.
Quuxplusone commented 8 years ago

Attached file_28652.txt (502 bytes, text/plain): Potential fix on trunk

Quuxplusone commented 6 years ago

I stumbled across this old bug because we're hitting this issue as well. Chris, I took your patch and applied it in https://reviews.llvm.org/D49330. In the past two years since this bug was filed, have you just been working around by manually adding -lm when using compiler-rt?

Quuxplusone commented 6 years ago 
(In reply to Jordan Rupprecht from comment #11)
> I stumbled across this old bug because we're hitting this issue as well.
> Chris, I took your patch and applied it in https://reviews.llvm.org/D49330.
> In the past two years since this bug was filed, have you just been working
> around by manually adding -lm when using compiler-rt?

Yes, I created a linker script, as seen here:

https://github.com/elkrejzi/pacman/blob/master/pkgbuild/llvm/PKGBUILD#L272