[llvm-bugs] [Bug 51389] New: compiler-rt build fails to find builtins on Darwin

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Aug 6 10:43:50 PDT 2021


https://bugs.llvm.org/show_bug.cgi?id=51389

            Bug ID: 51389
           Summary: compiler-rt build fails to find builtins on Darwin
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: compiler-rt
          Assignee: unassignedbugs at nondot.org
          Reporter: phosek at chromium.org
                CC: chris.bieneman at me.com, dan at su-root.co.uk,
                    llvm-bugs at lists.llvm.org, smeenai at fb.com

This was uncovered [D107501](https://reviews.llvm.org/D107501) which uncovered
several CMake check failures:

```
Performing C++ SOURCE FILE Test COMPILER_RT_HAS_G_FLAG failed with the
following output:
Change Dir:
/Users/phosek/llvm/build/fuchsia/runtimes/runtimes-bins/CMakeFiles/CMakeTmp

Run Build Command(s):/Users/phosek/.brew/bin/ninja cmTC_85a84 && [1/2] Building
CXX object CMakeFiles/cmTC_85a84.dir/src.cxx.o
[2/2] Linking CXX executable cmTC_85a84
FAILED: cmTC_85a84
: && /Users/phosek/llvm/build/fuchsia/./bin/clang++
--target=x86_64-apple-darwin20.6.0 -stdlib=libc++ -fPIC
-fvisibility-inlines-hidden -Werror=date-time
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor
-Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wstring-conversion
-Wmisleading-indentation -fdiagnostics-color
-ffile-prefix-map=/Users/phosek/llvm/build/fuchsia/runtimes/runtimes-bins=../build/fuchsia/runtimes/runtimes-bins
-ffile-prefix-map=/Users/phosek/llvm/llvm-project/= -no-canonical-prefixes 
-nostdinc++ -nostdlib++ -nodefaultlibs -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk
-Wl,-search_paths_first -Wl,-headerpad_max_install_names -stdlib=libc++
CMakeFiles/cmTC_85a84.dir/src.cxx.o -o cmTC_85a84  -lc  -lNOTFOUND && :
clang++: warning: argument unused during compilation: '-nostdinc++'
[-Wunused-command-line-argument]
ld: library not found for -lNOTFOUND
clang++: error: linker command failed with exit code 1 (use -v to see
invocation)
ninja: build stopped: subcommand failed.
```

The problem is that
[find_compiler_rt_library](https://github.com/llvm/llvm-project/blob/772d2093fc30b545df61c25d3b05a90ed2909e92/compiler-rt/cmake/config-ix.cmake#L19)
we use to find builtins fails on Darwin because the library isn't called
`libclang_rt.builtins.a` there, rather it's called `libclang_rt.$os.a` where
`$os` can be `osx`, `ios`, etc. Therefore, `find_compiler_rt_library` returns
`NOTFOUND` but we don't validate the result before appending it to
[CMAKE_REQUIRED_LIBRARIES](https://github.com/llvm/llvm-project/blob/772d2093fc30b545df61c25d3b05a90ed2909e92/compiler-rt/cmake/config-ix.cmake#L35).

Two possible solutions I can think of for addressing this issue:

1. If `find_compiler_rt_library` is used on `if (APPLE)`, then replace
`builtins` with `osx`. This feels a bit hacky but should be sufficient since we
never run CMake on other systems like iOS as far as I'm aware.

2. Modify Clang so that `-print-libgcc-file-name` prints the correct value on
Darwin. Currently, it'd print
`lib/clang/14.0.0/lib/x86_64-unknown-fuchsia/libclang_rt.builtins.a` but that's
incorrect. The problem is that `-print-libgcc-file-name` in
[Driver](https://github.com/llvm/llvm-project/blob/c120edc7b3e1907127c3107b30e2667f1fde1ee2/clang/lib/Driver/Driver.cpp#L1877)
uses the generic logic from `ToolChain`,
[Darwin](https://github.com/llvm/llvm-project/blob/c120edc7b3e1907127c3107b30e2667f1fde1ee2/clang/lib/Driver/ToolChains/Darwin.cpp#L1091)
toolchain uses its own custom logic that's different. Addressing this is likely
going to require some refactoring of the ToolChain and Darwin toolchain logic
but may be more preferable as a solution in the long run.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210806/dfa7672d/attachment-0001.html>


More information about the llvm-bugs mailing list