yunlian, I think  you found this problem before. 
(sysroot missing? )

please take a look. 

It seems this is not related to sysroot.
The linker commandline is
"/usr/local/google/home/yunlian/haha/bin/x86_64-cros-linux-gnu-ld" --sysroot=/usr/local/google/home/yunlian/haha/usr/x86_64-cros-linux-gnu -pie -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out Scrt1.o crti.o /usr/local/google/home/yunlian/haha/usr/bin/../lib/gcc/x86_64-cros-linux-gnu/4.9.x/crtbeginS.o -L/usr/local/google/home/yunlian/haha/usr/bin/../lib/gcc/x86_64-cros-linux-gnu/4.9.x /tmp/main-1b7b62.o /usr/local/google/home/yunlian/haha/usr/lib64/clang/5.0.0/lib/linux/libclang_rt.builtins-x86_64.a -lgcc_eh -lc /usr/local/google/home/yunlian/haha/usr/lib64/clang/5.0.0/lib/linux/libclang_rt.builtins-x86_64.a -lgcc_eh /usr/local/google/home/yunlian/haha/usr/bin/../lib/gcc/x86_64-cros-linux-gnu/4.9.x/crtendS.o crtn.o 

two things:
- many gcc paths are relative to lib/ which means if those don't exist, it all falls down.  workaround:
  mkdir usr/x86_64-cros-linux-gnu/lib
  mkdir usr/x86_64-cros-linux-gnu/usr/lib
- we're wrapping libc.so because it has an interpreter set and thus we think it's a normal executable ELF (which it is because of glibc trickery).  i'm not sure there's a way to disambiguate this from PIEs which means we'll need to special case it.  could update scripts/cros_setup_toolchains.py to undo the lddtree generated wrapper script.

Thanks Mike!

For 1) I can add these two dir in cros_setup_toolchains.py

For 2) Why did we create the wrapper script? I do not want to break anything by removing the wrapper.

(2) we aren't creating the wrapper explicitly.  we're using lddtree to copy in all of the files and telling it to generate wrappers as needed, but that heuristic is failing when told to copy libc.so itself.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/196e8f4935aa35c7163b40240bb9d972797d1502

commit 196e8f4935aa35c7163b40240bb9d972797d1502
Author: Yunlian Jiang <yunlian@google.com>
Date: Thu Sep 21 08:08:03 2017

cros_setup_toolchain: Do not create wrapper for glibc.

We do not want to have another wrapper over libc and this causes
the standalone toolchain fails to link a simple program.

BUG= chromium:766827 
TEST=create toolchain tarball and unpack it outside chroot.
     ./bin/x86_64-cros-linux-gnu-clang -shared -o foo.so  -lm a.c
     works

Change-Id: Ie7cb08bc47cfb9c4e8d104c6db5c40eb16211c79
Reviewed-on: https://chromium-review.googlesource.com/675574
Commit-Ready: Yunlian Jiang <yunlian@chromium.org>
Tested-by: Yunlian Jiang <yunlian@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/196e8f4935aa35c7163b40240bb9d972797d1502/scripts/cros_setup_toolchains.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/5ad6b5147f60522248d82c6f53bca94ec1e4807a

commit 5ad6b5147f60522248d82c6f53bca94ec1e4807a
Author: Yunlian Jiang <yunlian@google.com>
Date: Thu Sep 21 10:34:28 2017

cros_setup_toolchain: Create lib dirs to find gcc path.

Many gcc paths are relative to lib, so we need these lib dirs to
help compiler find the correct gcc paths to find Scrt1.o, crti.o and
so on.

BUG= chromium:766827 
TEST=cros_setup_toolchains -t x86_64-cros-linux-gnu --create-packages
     usr/x86_64-cros-linux-gnu/lib usr/x86_64-cros-linux-gnu/usr/lib
     was created.

Change-Id: I708cd6178ffcd767c0cd11d175ff4da16e6f13b0
Reviewed-on: https://chromium-review.googlesource.com/675563
Commit-Ready: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Yunlian Jiang <yunlian@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/5ad6b5147f60522248d82c6f53bca94ec1e4807a/scripts/cros_setup_toolchains.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/4331fc634d0cb63598289538ca3dd97bedfb1800

commit 4331fc634d0cb63598289538ca3dd97bedfb1800
Author: Mike Frysinger <vapier@chromium.org>
Date: Fri Sep 29 06:26:39 2017

cros_setup_toolchains: do not wrap libpthread.so

We have to whitelist libpthread.so too since it makes itself executable.

BUG= chromium:766827 
TEST=`cros_setup_toolchains --create-packages -t x86_64-cros-linux-gnu` doesn't wrap anymore

Change-Id: I6544822ff38779b401d66408c83dcb9387eb11a6
Reviewed-on: https://chromium-review.googlesource.com/690797
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Ian Coolidge <icoolidge@google.com>
Reviewed-by: Yunlian Jiang <yunlian@chromium.org>

[modify] https://crrev.com/4331fc634d0cb63598289538ca3dd97bedfb1800/scripts/cros_setup_toolchains.py

some more cases Ian raised with us:
- libpthread.so was being wrapped like libc.so.  addressed in CL:690797 by just tweaking the interp check in CL:675574.

- our native ELF test to pick up symlinks to programs we expect to run ends up catching x86_64-cros-linux-gnu libs too
$ file usr/x86_64-cros-linux-gnu/usr/lib64/libanl.so
.../libanl.so: POSIX shell script, ASCII text executable
$ ls -l /usr/x86_64-cros-linux-gnu/usr/lib64/libanl.so 
lrwxrwxrwx 1 root root 23 Sep 26 15:34 /usr/x86_64-cros-linux-gnu/usr/lib64/libanl.so -> ../../lib64/libanl.so.1

this one we *mostly* address by adjusting the check to only wrap symlinks to wrappers and not symlinks to any ELF (as that's what we actually want).

- we're wrapping target programs that happen to also be native ELFs:
$ file usr/x86_64-cros-linux-gnu/usr/bin/getent*
.../getent:     POSIX shell script, ASCII text executable
.../getent.elf: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=e5c43912d5ed13af64eb0819c022f6f5f4419581, stripped

i don't think it's worth addressing this as we don't have a use case (yet?) for using those target programs.  if it comes up, we can re-evaluate.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/221bd82440159b189d1fab1f28586794f6a3d9ae

commit 221bd82440159b189d1fab1f28586794f6a3d9ae
Author: Mike Frysinger <vapier@chromium.org>
Date: Tue Oct 03 21:26:12 2017

cros_setup_toolchains: don't wrap symlinks to libraries

Our native ELF check catches target libraries when the target is x86_64,
and we end up wrapping libs with shell scripts that makes no sense.  The
point of this wrapping logic is to add shell scripts for symlinks to any
programs that we wrapped, not to add shell scripts for any symlink.

Nest the symlink check under the interp wrapper check so it only happens
when it makes sense.

BUG= chromium:766827 
TEST=`cros_setup_toolchains --create-packages -t x86_64-cros-linux-gnu` doesn't wrap anymore

Change-Id: I90485f3cf6ebeb2be94701124e383aeb9d702021
Reviewed-on: https://chromium-review.googlesource.com/691342
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Yunlian Jiang <yunlian@chromium.org>

[modify] https://crrev.com/221bd82440159b189d1fab1f28586794f6a3d9ae/scripts/cros_setup_toolchains.py

i think all the known edge cases are covered now

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/785b0c3604c1e90bfaaf230103ddddd56fa1a788

commit 785b0c3604c1e90bfaaf230103ddddd56fa1a788
Author: Mike Frysinger <vapier@chromium.org>
Date: Mon Oct 09 12:11:35 2017

cros_setup_toolchains: add a post-cross-compiler set of packages

The rust package bundles both the toolchain and its runtime libraries
in a single build.  This means that we can't build the compiler first
and then build the runtime libs once the cross-compilers are available.
To support this, we add a new phase for building packages after all the
cross-compilers have been built & installed.

Now the sdk bot looks like:
- build host packages (all the normal sdk packages)
- build cross-compilers (all the cross-xxx/ packages)
- build host-cross-post packages (like rust)

Since a rust binary doesn't yet exist, we have to mark it skip it on
existing builds.  Once the SDK bot finishes building everything, we
can flip the bit so it gets installed everywhere from binpkgs.

BUG= chromium:766827 
TEST=precq passes (which skips the new rust package)
TEST=`./update_chroot --nousepkg` installs the new rust package

Change-Id: Ibffe1161be347d3da298d84726c9f20ae67babc9
Reviewed-on: https://chromium-review.googlesource.com/699064
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>

[modify] https://crrev.com/785b0c3604c1e90bfaaf230103ddddd56fa1a788/scripts/cros_setup_toolchains.py

Mike, the CL is breaking toolchain builders when building llvm-next with latest-toolchain.

https://uberchromegw.corp.google.com/i/chromiumos.tryserver/builders/llvm_next_toolchain/builds/760

i used the wrong bug ... that should have been  issue 751852