llvm: clang used in Simple Chrome workflow is confused about its own identity |
|||||
Issue description
I am seeing some weird behavior with clang on simple chrome:
.cros_cache/chrome-sdk/t
arballs/daisy+8530.0.0+target_toolchain/usr/bin/clang++ /tmp/hello.o
/tmp/hello.o: In function `main':
/tmp/hello.cpp:(.text+0xa): undefined reference to `std::cout'
/tmp/hello.cpp:(.text+0x24): undefined reference to `std::basic_ostream<char, std::char_traits<char> >
& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char c
onst*)'
This is happening because clang is not adding -lstdc++ to the link line.
clang should do that whenver it recognizes itself as clang++.
This works fine within the chromeos chroot.
it turns out that clang in Simple Chrome is executed through ld-linux.so (not sure why this is)
.cros_cache/chrome-sdk/tarballs/daisy+8530.0.0+target_toolchain/usr/bin/clang
#!/bin/sh
if ! base=$(realpath "$0" 2>/dev/null); then
case $0 in
/*) base=$0;;
*) base=${PWD:-`pwd`}/$0;;
esac
fi
basedir=${base%/*}
exec "${basedir}/../../lib/ld-linux-x86-64.so.2" --library-path "${basedir}/../../lib:${basedir}/../lib64" --inhibit-rpath '' "${base}.elf" "$@"
within this bash script $0 ends up in clang++ but after the invocation through ld-linux.so there is no trace of the name "clang++". I think this is the reason why clang does not identify itself correctly.
There is an interesting thread related to this in https://marc.info/?l=glibc-alpha&m=146150049816403&w=2
POssible solutions
- change the name of clang.elf to something like elf.clang and elf.clang++ and call the appropriate one depending on the value of $0.
- or put the real clang in a different directory (together with clang++)
,
Jul 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/chromite/+/a8127bb7fb34a4fcc2d72fab07961b08b647c101 commit a8127bb7fb34a4fcc2d72fab07961b08b647c101 Author: Rahul Chaudhry <rahulchaudhry@chromium.org> Date: Fri Jul 22 22:53:17 2016 Fix wrapper shell scripts and symlinks for invoking clang++ In a typical installation, clang++ symlinks to clang, which symlinks to the elf executable. The executable distinguishes between clang and clang++ based on argv[0]. When invoked through the LdsoWrapper, argv[0] always contains the path to the executable elf file, making clang/clang++ invocations indistinguishable. This CL adjusts the symlinks and wrappers so clang++ invocation works correctly. BUG= chromium:628524 TEST='cros_setup_toolchains --create-packages -t x86_64-cros-linux-gnu' TEST=Used x86_64-cros-linux-gnu.tar.xz to successfully build chrome for panther (simple-chrome). TEST='cros_setup_toolchains --create-packages -t i686-pc-linux-gnu' TEST=Used i686-pc-linux-gnu.tar.xz to successfully build chrome for x86-zgb (simple-chrome). TEST='cros_setup_toolchains --create-packages -t armv7a-cros-linux-gnueabi' TEST=Used armv7a-cros-linux-gnueabi.tar.xz to successfully build chrome for daisy (simple-chrome). Change-Id: Id2ecb65b99226b65a3da4197c09eda28c5fdefca Reviewed-on: https://chromium-review.googlesource.com/362682 Commit-Ready: Luis Lozano <llozano@chromium.org> Tested-by: Luis Lozano <llozano@chromium.org> Reviewed-by: Luis Lozano <llozano@chromium.org> [modify] https://crrev.com/a8127bb7fb34a4fcc2d72fab07961b08b647c101/scripts/cros_setup_toolchains.py
,
Jul 28 2016
,
Aug 1 2016
the shell scripts & ld.so indirection are needed for the standalone toolchains to actually be standalone, otherwise the version of glibc used would be the host one which would be bad. i think this is another argv[0] issue that should be fixed by the patch i sent uptsream: https://sourceware.org/ml/libc-alpha/2016-04/msg00576.html i need to finish that up and then we can revert that CL.
,
Aug 1 2016
Sounds good (I assume you mean reverting this CL and adding the new --argv0 flag in the LdsoWrappers). Feel free to reopen this issue when the new Ldso is available.
,
Aug 19 2016
,
Aug 29 2016
,
Aug 29 2016
bulk verified |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by bugdroid1@chromium.org
, Jul 27 2016