Using LLD from the official nightly docker image

I want to try out the LLVM linker to see if it will speed things up for me. I have worked out how to help lld find all the system libraries but it sounds like there's something wrong when build scripts (which I guess are compiled and executed?) not finding those libraries.

I am using the rustlang/rust:nightly container (freshly pulled today). The container is booted like this:

docker run --name=rust --workdir=/datascience-web --rm -it -p 8000:8000 -v $(shell pwd):/datascience-web -v $(shell pwd)/../../samuel-rs:/samuel-rs -v $(shell pwd)/target/linux-env-cargo-git:/usr/local/cargo/git -v $(shell pwd)/target/linux-env-cargo-registry:/usr/local/cargo/registry rustlang/rust:nightly bash

Then from inside the container, I got to /code and run:

RUSTFLAGS='-C linker=rust-lld -L /usr/lib/x86_64-linux-gnu -L /usr/lib/gcc/x86_64-linux-gnu/8' cargo build
   Compiling libc v0.2.65
   Compiling proc-macro2 v1.0.6
   Compiling byteorder v1.3.2
   Compiling log v0.4.8
   Compiling syn v1.0.5
   Compiling semver v0.9.0
error: failed to run custom build command for `byteorder v1.3.2`

Caused by:
  process didn't exit successfully: `/code/target/debug/build/byteorder-ce648015d7f0b8ef/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
warning: build failed, waiting for other jobs to finish...
error: failed to run custom build command for `libc v0.2.65`

Caused by:
  process didn't exit successfully: `/code/target/debug/build/libc-00921b43cd2fe1bc/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
warning: build failed, waiting for other jobs to finish...
error: failed to run custom build command for `proc-macro2 v1.0.6`

Caused by:
  process didn't exit successfully: `/code/target/debug/build/proc-macro2-12e6e3f6412e607e/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
warning: build failed, waiting for other jobs to finish...
error: failed to run custom build command for `log v0.4.8`

Caused by:
  process didn't exit successfully: `/code/target/debug/build/log-f937be6d994db414/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
warning: build failed, waiting for other jobs to finish...
error: failed to run custom build command for `syn v1.0.5`

Caused by:
  process didn't exit successfully: `/code/target/debug/build/syn-38e19eef1c830c5c/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
warning: build failed, waiting for other jobs to finish...
error: build failed
make: *** [Makefile:36: build-linux-lld] Error 101

It looks like those build-script-build things should be good to go:

# file /code/target/debug/build/syn-38e19eef1c830c5c/build-script-build
/code/target/debug/build/syn-38e19eef1c830c5c/build-script-build: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped
# root@59255e7d6349:/code# ldd /code/target/debug/build/syn-38e19eef1c830c5c/build-script-build
	linux-vdso.so.1 (0x00007ffffc9de000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe303b87000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe303b7d000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe303b5c000)
	libgcc_s.so.1 => /usr/lib/gcc/x86_64-linux-gnu/8/libgcc_s.so.1 (0x00007fe303b42000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe303981000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe3037fe000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fe3037f7000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fe303b9d000)
# /code/target/debug/build/syn-38e19eef1c830c5c/build-script-build
Segmentation fault # :( 

anyone know what's wrong with those build-script-build files? What purpose do they have and why would they now blow up?

Could you run the build script in a debugger amd get a backtrace? For example:

$ gdb /path/to/build-script-build
(gdb) run
(gdb) bt

Note that running a debugger inside of Docker requires ptrace privileges. A simple if inelegantly blunt way to get them is to add a --privileged flag to your docker command line.

Great idea, I installed gdb in to the rustlang/rust:nightly container with apt update; apt install -y rust-gdb. Hopefully that helps with demangling rust symbols.

# rust-gdb /datascience-web/target/debug/build/log-f937be6d994db414/build-script-build
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /datascience-web/target/debug/build/log-f937be6d994db414/build-script-build...done.
(gdb) run
Starting program: /datascience-web/target/debug/build/log-f937be6d994db414/build-script-build

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff7ffc01b in std::sys::unix::mutex::Mutex::lock () at src/libstd/sys/unix/mutex.rs:55
#2  std::sys_common::mutex::Mutex::raw_lock () at src/libstd/sys_common/mutex.rs:36
#3  std::sys_common::mutex::Mutex::lock () at src/libstd/sys_common/mutex.rs:42
#4  std::sys::unix::args::imp::really_init () at src/libstd/sys/unix/args.rs:76
#5  std::sys::unix::args::imp::ARGV_INIT_ARRAY::init_wrapper () at src/libstd/sys/unix/args.rs:103

Does anyone know if there's a Rust nightly which is compatible with LLD? I'd be OK rolling back to try out the linker just to see if it's worth it.

--cap-add=SYS_PTRACE instead of --privileged should be enough :wink: (maybe with a --security-opt seccomp:unconfined on older versions of Docker)

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.