Skip to content

[libc][startup] set --target= for linker when cross compiling #96342

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 21, 2024

Conversation

nickdesaulniers
Copy link
Member

Otherwise the startup objects will fail to link since they were cross compiled,
but the linker is not informed of the intent to cross compile, which results in
linker errors when the host architecture does not match the target
architecture.

Otherwise the startup objects will fail to link since they were cross compiled,
but the linker is not informed of the intent to cross compile, which results in
linker errors when the host architecture does not match the target
architecture.
@llvmbot
Copy link
Member

llvmbot commented Jun 21, 2024

@llvm/pr-subscribers-libc

Author: Nick Desaulniers (paternity leave) (nickdesaulniers)

Changes

Otherwise the startup objects will fail to link since they were cross compiled,
but the linker is not informed of the intent to cross compile, which results in
linker errors when the host architecture does not match the target
architecture.


Full diff: https://github.com/llvm/llvm-project/pull/96342.diff

1 Files Affected:

  • (modified) libc/startup/linux/CMakeLists.txt (+1-1)
diff --git a/libc/startup/linux/CMakeLists.txt b/libc/startup/linux/CMakeLists.txt
index 68f68ff45aa9e..31c0ada31aebd 100644
--- a/libc/startup/linux/CMakeLists.txt
+++ b/libc/startup/linux/CMakeLists.txt
@@ -26,7 +26,7 @@ function(merge_relocatable_object name)
   )
   # Pass -r to the driver is much cleaner than passing -Wl,-r: the compiler knows it is
   # a relocatable linking and will not pass other irrelevant flags to the linker.
-  target_link_options(${relocatable_target} PRIVATE -r -nostdlib)
+  target_link_options(${relocatable_target} PRIVATE -r -nostdlib --target=${explicit_target_triple})
   set_target_properties(
     ${relocatable_target}
     PROPERTIES

Copy link
Contributor

@jhuber6 jhuber6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch.

@nickdesaulniers nickdesaulniers merged commit 32d05db into llvm:main Jun 21, 2024
6 of 7 checks passed
@nickdesaulniers nickdesaulniers deleted the arm_runtimes_cross2 branch June 21, 2024 20:30
@llvm-ci
Copy link
Collaborator

llvm-ci commented Jun 21, 2024

LLVM Buildbot has detected a new failure on builder libc-aarch64-ubuntu-fullbuild-dbg running on libc-aarch64-ubuntu while building libc at step 4 "annotate".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/71/builds/541

Here is the relevant piece of the build log for the reference:

Step 4 (annotate) failure: 'python ../llvm-zorg/zorg/buildbot/builders/annotated/libc-linux.py ...' (failure)
...
-- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
-- Performing Test HAVE_POSIX_REGEX -- success
-- Performing Test HAVE_STEADY_CLOCK -- success
-- Performing Test HAVE_PTHREAD_AFFINITY -- failed to compile
-- Configuring done
-- Generating done
-- Build files have been written to: /home/libc-buildbot/libc-aarch64-ubuntu/libc-aarch64-ubuntu-fullbuild-dbg/build
@@@BUILD_STEP build libc@@@
Running: ninja libc
[1/1] Linking CXX executable projects/libc/startup/linux/crt1.o
FAILED: projects/libc/startup/linux/crt1.o 
: && /usr/bin/clang++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -g -r -nostdlib --target= projects/libc/startup/linux/aarch64/CMakeFiles/libc.startup.linux.aarch64.start.dir/start.cpp.o projects/libc/startup/linux/aarch64/CMakeFiles/libc.startup.linux.aarch64.tls.dir/tls.cpp.o projects/libc/startup/linux/CMakeFiles/libc.startup.linux.do_start.dir/do_start.cpp.o -o projects/libc/startup/linux/crt1.o   && :
clang: error: unable to execute command: Executable "g++" doesn't exist!
clang: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
['ninja', 'libc'] exited with return code 1.
The build step threw an exception...
Traceback (most recent call last):
  File "../llvm-zorg/zorg/buildbot/builders/annotated/libc-linux.py", line 163, in step
    yield
  File "../llvm-zorg/zorg/buildbot/builders/annotated/libc-linux.py", line 120, in main
    run_command(['ninja', 'libc'])
  File "../llvm-zorg/zorg/buildbot/builders/annotated/libc-linux.py", line 178, in run_command
    util.report_run_cmd(cmd, cwd=directory)
  File "/home/libc-buildbot/libc-aarch64-ubuntu/libc-aarch64-ubuntu-fullbuild-dbg/llvm-zorg/zorg/buildbot/builders/annotated/util.py", line 49, in report_run_cmd
    subprocess.check_call(cmd, shell=shell, *args, **kwargs)
  File "/usr/lib/python2.7/subprocess.py", line 190, in check_call
    raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '['ninja', 'libc']' returned non-zero exit status 1
@@@STEP_FAILURE@@@
@@@BUILD_STEP build libc-startup@@@
Running: ninja libc-startup
[1/1] Linking CXX executable projects/libc/startup/linux/crt1.o
FAILED: projects/libc/startup/linux/crt1.o 
: && /usr/bin/clang++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -g -r -nostdlib --target= projects/libc/startup/linux/aarch64/CMakeFiles/libc.startup.linux.aarch64.start.dir/start.cpp.o projects/libc/startup/linux/aarch64/CMakeFiles/libc.startup.linux.aarch64.tls.dir/tls.cpp.o projects/libc/startup/linux/CMakeFiles/libc.startup.linux.do_start.dir/do_start.cpp.o -o projects/libc/startup/linux/crt1.o   && :
clang: error: unable to execute command: Executable "g++" doesn't exist!
clang: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
['ninja', 'libc-startup'] exited with return code 1.
The build step threw an exception...
Traceback (most recent call last):
  File "../llvm-zorg/zorg/buildbot/builders/annotated/libc-linux.py", line 163, in step
    yield
  File "../llvm-zorg/zorg/buildbot/builders/annotated/libc-linux.py", line 124, in main
    run_command(['ninja', 'libc-startup'])
  File "../llvm-zorg/zorg/buildbot/builders/annotated/libc-linux.py", line 178, in run_command
    util.report_run_cmd(cmd, cwd=directory)
  File "/home/libc-buildbot/libc-aarch64-ubuntu/libc-aarch64-ubuntu-fullbuild-dbg/llvm-zorg/zorg/buildbot/builders/annotated/util.py", line 49, in report_run_cmd
    subprocess.check_call(cmd, shell=shell, *args, **kwargs)

@jhuber6
Copy link
Contributor

jhuber6 commented Jun 21, 2024

That's an interesting error, it's probably using the fallback GCC toolchain in clang since it can't fully parse the triple or something.

@llvm-ci
Copy link
Collaborator

llvm-ci commented Jun 21, 2024

LLVM Buildbot has detected a new failure on builder libc-x86_64-debian-gcc-fullbuild-dbg running on libc-x86_64-debian-fullbuild while building libc at step 4 "annotate".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/131/builds/532

Here is the relevant piece of the build log for the reference:

Step 4 (annotate) failure: 'python ../llvm-zorg/zorg/buildbot/builders/annotated/libc-linux.py ...' (failure)
...
-- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
-- Performing Test HAVE_POSIX_REGEX -- success
-- Performing Test HAVE_STEADY_CLOCK -- success
-- Performing Test HAVE_PTHREAD_AFFINITY -- success
-- Configuring done
-- Generating done
-- Build files have been written to: /home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/build
@@@BUILD_STEP build libc@@@
Running: ninja libc
[1/1] Linking CXX executable projects/libc/startup/linux/crt1.o
FAILED: projects/libc/startup/linux/crt1.o 
: && /usr/bin/g++ -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -g -r -nostdlib --target= projects/libc/startup/linux/x86_64/CMakeFiles/libc.startup.linux.x86_64.start.dir/start.cpp.o projects/libc/startup/linux/x86_64/CMakeFiles/libc.startup.linux.x86_64.tls.dir/tls.cpp.o projects/libc/startup/linux/CMakeFiles/libc.startup.linux.do_start.dir/do_start.cpp.o -o projects/libc/startup/linux/crt1.o   && :
g++: error: unrecognized command-line option ‘--target=’; did you mean ‘--target-ar=’?
ninja: build stopped: subcommand failed.
['ninja', 'libc'] exited with return code 1.
The build step threw an exception...
Traceback (most recent call last):
  File "/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/build/../llvm-zorg/zorg/buildbot/builders/annotated/libc-linux.py", line 163, in step
    yield
  File "/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/build/../llvm-zorg/zorg/buildbot/builders/annotated/libc-linux.py", line 120, in main
    run_command(['ninja', 'libc'])
  File "/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/build/../llvm-zorg/zorg/buildbot/builders/annotated/libc-linux.py", line 178, in run_command
    util.report_run_cmd(cmd, cwd=directory)
  File "/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-zorg/zorg/buildbot/builders/annotated/util.py", line 49, in report_run_cmd
    subprocess.check_call(cmd, shell=shell, *args, **kwargs)
  File "/usr/lib/python3.11/subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['ninja', 'libc']' returned non-zero exit status 1.
@@@STEP_FAILURE@@@
@@@BUILD_STEP build libc-startup@@@
Running: ninja libc-startup

@nickdesaulniers
Copy link
Member Author

Will revert for now. Perhaps related to runtimes build vs not.

@nickdesaulniers
Copy link
Member Author

: && /usr/bin/clang++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -g -r -nostdlib --target= projects/libc/startup/linux/aarch64/CMakeFiles/libc.startup.linux.aarch64.start.dir/start.cpp.o projects/libc/startup/linux/aarch64/CMakeFiles/libc.startup.linux.aarch64.tls.dir/tls.cpp.o projects/libc/startup/linux/CMakeFiles/libc.startup.linux.do_start.dir/do_start.cpp.o -o projects/libc/startup/linux/crt1.o && :

Is the command invocation on the failing buildbot, implying that explicit_target_triple isn't getting set for non Runtimes builds. I wonder if we can just drop support for non-runtimes builds; runtimes builds are the future of configuring llvm.

@nickdesaulniers
Copy link
Member Author

ah, the GCC build is failing for the host build. We don't set explicit_target_triple at all when targeting the host. Can fix forward that.

nickdesaulniers added a commit to nickdesaulniers/llvm-project that referenced this pull request Jun 21, 2024
We only need to set `--target=` for LLD when cross compiling. This should fix
the host build using BFD.

Fixes: llvm#96342
@nickdesaulniers
Copy link
Member Author

#96357 is the fix for GCC host builds. Another one inbound for aarch64.

@nickdesaulniers
Copy link
Member Author

#96357 is the fix for GCC host builds. Another one inbound for aarch64.

Nevermind, #96357 will fix both build breakages. The aarch64 build is native to the host.

nickdesaulniers added a commit that referenced this pull request Jun 21, 2024
We only need to set `--target=` for LLD when cross compiling. This should fix
the host build using BFD or targeting the host.

Fixes: #96342
AlexisPerry pushed a commit to llvm-project-tlp/llvm-project that referenced this pull request Jul 9, 2024
…6342)

Otherwise the startup objects will fail to link since they were cross compiled,
but the linker is not informed of the intent to cross compile, which results in
linker errors when the host architecture does not match the target
architecture.
AlexisPerry pushed a commit to llvm-project-tlp/llvm-project that referenced this pull request Jul 9, 2024
…96357)

We only need to set `--target=` for LLD when cross compiling. This should fix
the host build using BFD or targeting the host.

Fixes: llvm#96342
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants