Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: rustc tries to call `cc` as a linker but there's no such command in the container: [remote:13]: mprchlik@dhcp-1-137 ~ $ docker run -it --rm rhscl-tech-preview/rust-toolset-7-rhel7 /bin/bash bash-4.2$ echo 'fn main() { println!("Hello world from containerized rustc!"); }' > t.rs bash-4.2$ rustc -o t t.rs error: could not exec the linker `cc`: No such file or directory (os error 2) | = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/opt/rh/rust-toolset-7/root/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "t.0.o" "-o" "t" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "/opt/rh/rust-toolset-7/root/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/opt/rh/rust-toolset-7/root/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-3c41e96dc22e83d1.rlib" "/opt/rh/rust-toolset-7/root/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-eb5ec9bbb739e4ca.rlib" "/opt/rh/rust-toolset-7/root/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-46ec5c900f49ef1c.rlib" "/opt/rh/rust-toolset-7/root/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_unicode-c4a074a05d16e29b.rlib" "/opt/rh/rust-toolset-7/root/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-8e645bc8d6ac9940.rlib" "/opt/rh/rust-toolset-7/root/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-f09596a53bb16b29.rlib" "/opt/rh/rust-toolset-7/root/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-36f47870e81ba3b9.rlib" "/opt/rh/rust-toolset-7/root/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_system-40cca488d50c4fdc.rlib" "/opt/rh/rust-toolset-7/root/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-2337020bc2f1f2af.rlib" "/opt/rh/rust-toolset-7/root/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-628f18e7c718cb65.rlib" "/opt/rh/rust-toolset-7/root/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-e0204d9003a3142f.rlib" "-Wl,-Bdynamic" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "gcc_s" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util" error: aborting due to previous error(s) bash-4.2$ This works nicely when used with rust-toolset-7 collection directly. Few things that might be connected to this (all commands running in the container): bash-4.2$ rpm -qa | grep -E 'llvm|rust-toolset|devtoolset' | sort devtoolset-4-gcc-5.2.1-2.2.el7.x86_64 devtoolset-4-runtime-4.0-9.el7.x86_64 llvm-toolset-7-llvm-libs-4.0.1-3.el7.x86_64 llvm-toolset-7-runtime-4.0.1-2.el7.x86_64 rust-toolset-7-1.19.0-2.el7.x86_64 rust-toolset-7-cargo-0.20.0-1.el7.x86_64 rust-toolset-7-runtime-1.19.0-2.el7.x86_64 rust-toolset-7-rust-1.19.0-1.el7.x86_64 rust-toolset-7-rust-std-static-1.19.0-1.el7.x86_64 bash-4.2$ llvm and rust collections are enabled, DTS is not, but it is possible to enable it manually and call gcc: bash-4.2$ echo $X_SCLS llvm-toolset-7 rust-toolset-7 bash-4.2$ bash-4.2$ bash-4.2$ type gcc bash: type: gcc: not found bash-4.2$ bash-4.2$ bash-4.2$ scl enable devtoolset-4 'bash -c "type gcc"' gcc is /opt/rh/devtoolset-4/root/usr/bin/gcc bash-4.2$ bash-4.2$ scl enable devtoolset-4 bash bash-4.2$ echo $X_SCLS llvm-toolset-7 rust-toolset-7 devtoolset-4 bash-4.2$ rustc -o t t.rs bash-4.2$ ./t Hello world from containerized rustc! bash-4.2$ Version-Release number of selected component (if applicable): rhscl-tech-preview/rust-toolset-7-rhel7 871a5b58059e (seems to be the only available version) How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Hmm... rust-toolset-7-rust has a simple "Requires: gcc" to use as a linker. It doesn't need a newer DTS version, so I expected to just get gcc from the base OS. However, all past versions of DTS are available in the buildroot, and it seems every devtoolset-*-gcc has a "Provides:gcc = %{version}-%{release}". I guess yum picked one at random for me? That's not helpful without enabling the chosen SCL... I could use "Requires: /usr/bin/cc" instead, or else make devtoolset-7-gcc an explicit dependency. I'll ask the rest of the tools team for preferences.
There is no gcc at all in the image. That would need to be explicitly listed in the dockerfile before the image gets built.
I am surprised that gcc doesn't get pulled in via the rust.spec:186 Requires: gcc.
Ha! It's because for some reason, according to the build log, this dependency gets satisfied by devtoolset-3-gcc (!) and this isn't anywhere in the $PATH when accessing the image the usual way... http://download-node-02.eng.bos.redhat.com/brewroot/packages/rust-toolset-7-docker/7/2/data/logs/build.log Something is wrong here...
Radku, can you, please inspect the buildroot from the RCM persp?
(In reply to Martin Cermak from comment #2) > There is no gcc at all in the image. That would need to be explicitly > listed in the dockerfile before the image gets built. So, indeed, there is devtoolset-3-gcc in the image [1], and enabling this collection within the image works the problem around, so that rustc happily crunches the hello world program :-) ------- [1] /mnt/redhat/brewroot/packages/rust-toolset-7-docker/7/2/images/docker-image-4aefd870c2f40f1db2d4acb753a2ebf7523842483100805ade8157a0136c4e33.x86_64.tar.gz
We need to get rid of the devtoolset-3-xxxx packages from beta composes. They are pulled there due to unresolved require from devtoolset-7-dwz. More details in similar issue https://bugzilla.redhat.com/show_bug.cgi?id=1482066 where I have described in details where exactly is the problem.
I -think- that devtoolset-7-dwz.rpm should be happy with base rhel elfutils-libelf.rpm. See https://bugzilla.redhat.com/show_bug.cgi?id=1482066#c6 .
Sure but when you have several possibilities in repos which can satisfy yum dependence, how will you tell yum to take your desired package for dependence. No way, yum will use his own mechanism to determine which package is good and it will end with first successful. This doesn't ensure that your elfutils-libelf.rpm from RHEL will be used. Therefore we need to remove possibility to choose devtoolset-3 and devtoolset-4 packages from compose. From log is visible that devtoolset-3 package was taken from rhel-server-rhscl-beta-7-rpms, therefore new beta without devtoolest-3 and devtoolset-4 should help us. My conclusion is that we need new beta witout devtoolset-3 & devtoolset-4 packages.
Or to `Requires: /usr/bin/gcc` in the specfile. That seems to be correct from the specfile syntax perspective, and might help.
yes, that would help too
Verified with devtools-beta/rust-toolset-7-rhel7:7-5.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:3035