Closed ZelphirKaltstahl closed 1 year ago
Could you run with RUST_BACKTRACE=1
and post the result? (might not catch anything) And could you try running the binary directly (./target/debug/hello_world
) to verify it's not a cargo issue?
$ RUST_BACKTRACE=1 cargo run
Compiling hello_world v0.1.0 (/home/xiaolong/dev/rust/hello_world)
Finished dev [unoptimized + debuginfo] target(s) in 0.32s
Running `target/debug/hello_world`
Segmentation fault (core dumped)
$ RUST_BACKTRACE=1 ./target/debug/hello_world
Segmentation fault (core dumped)
I can't reproduce with the same target, same GCC version, same rust + cargo versions. Time for super verbose mode to see what's going on, could you do:
cargo clean
RUSTFLAGS="-C link-arg=-Wl,--verbose" RUSTC_LOG=rustc_codegen_ssa::back::link=info cargo build -vv
Can you try running the program in gdb and look at the backtrace of the segfault? gdb target/debug/hello_world
, then r
, then bt
Can you confirm that cc -m64
on a hello world C program creates a program that compiles and runs successfully? Ideally with the same env variables set (they are visible in the 4th line of the output you posted, the line starting with LC_ALL=C).
Few extra things to try chasing this down if you have the time:
rustup install 1.56 && cargo +1.56 run
) to see if this was a regression that was introduced at some point. If this works and you have time, you could try some more versions and bisect where the regression is@ZelphirKaltstahl how did you install Rust, are you emulating a classical filesystem with --emulate-fhs
or something similar? I'm not sure of how the Rust toolchain work under Guix.
I will try to answer all in sequence.
Can you try running the program in gdb and look at the backtrace of the segfault? gdb target/debug/hello_world, then r, then bt
It might be, that the gdb
backtrace is too long for pasting here (3.4MB) so I will try to upload as file instead … Nope, cannot do that either, Github says: "Something went really wrong, and we can't process that file. Try again." Not sure what to do now. Do you have any suggestions, where I could upload it? I could still make it a mega.nz link. If that is not good for you, please suggest an alternative, that does not require making an account. Here is the link.
Can you confirm that cc -m64 on a hello world C program creates a program that compiles and runs successfully? Ideally with the same env variables set (they are visible in the 4th line of the output you posted, the line starting with LC_ALL=C).
I am using the following code as a hello world program in C, found on some website:
#include <stdio.h>
int main()
{
printf("Hello World");
return 0;
}
When I use cc -m64
on it, it compiles to some a.out
file. When I run that using ./a.out
, I get a Segmentation fault (core dumped)
again. But I am not sure, which environment variables you mean. Which of the following lines?
$ RUSTFLAGS="-C link-arg=-Wl,--verbose" RUSTC_LOG=rustc_codegen_ssa::back::link=info cargo build -vv
Compiling hello_world v0.1.0 (/home/user/dev/rust/hello_world)
Running `CARGO=/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo CARGO_BIN_NAME=hello_world CARGO_CRATE_NAME=hello_world CARGO_MANIFEST_DIR=/home/user/dev/rust/hello_world CARGO_PKG_AUTHORS='' CARGO_PKG_DESCRIPTION='' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=hello_world CARGO_PKG_README='' CARGO_PKG_REPOSITORY='' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.1.0 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=1 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' CARGO_PRIMARY_PACKAGE=1 LD_LIBRARY_PATH='/home/user/dev/rust/hello_world/target/debug/deps:/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib:/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib' rustc --crate-name hello_world --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=272 --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=e22d40e86553def7 -C extra-filename=-e22d40e86553def7 --out-dir /home/user/dev/rust/hello_world/target/debug/deps -C incremental=/home/user/dev/rust/hello_world/target/debug/incremental -L dependency=/home/user/dev/rust/hello_world/target/debug/deps -C link-arg=-Wl,--verbose`
INFO rustc_codegen_ssa::back::link preparing Executable to "/home/user/dev/rust/hello_world/target/debug/deps/hello_world-e22d40e86553def7"
INFO rustc_codegen_ssa::back::link LC_ALL="C" PATH="/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/user/.cargo/bin:/home/hans/.config/guix/current/bin:/home/user/.config/guix/current/bin:/home/user/.config/guix/current/sbin:/home/user/.config/guix/current/bin:/home/user/.local/bin:/home/user/.guix-profile/bin:/home/user/.guix-profile/sbin:/home/user/.config/guix/current/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/user/.local/bin:/usr/lib/jvm/java-17-openjdk-amd64/bin:/usr/local/texlive/2022/bin/x86_64-linux" VSLANG="1033" "cc" "-m64" "/tmp/rustcX2BMCh/symbols.o" "/home/user/dev/rust/hello_world/target/debug/deps/hello_world-e22d40e86553def7.1jus6o66igae3ze0.rcgu.o" "/home/user/dev/rust/hello_world/target/debug/deps/hello_world-e22d40e86553def7.2tso0xryp4hk7njb.rcgu.o" "/home/user/dev/rust/hello_world/target/debug/deps/hello_world-e22d40e86553def7.30mjrv4l6r2a11zg.rcgu.o" "/home/user/dev/rust/hello_world/target/debug/deps/hello_world-e22d40e86553def7.3f3n7fk5va7dfy43.rcgu.o" "/home/user/dev/rust/hello_world/target/debug/deps/hello_world-e22d40e86553def7.3xvbrrewyhi5p5s1.rcgu.o" "/home/user/dev/rust/hello_world/target/debug/deps/hello_world-e22d40e86553def7.4xr9u3m81u6vkx31.rcgu.o" "/home/user/dev/rust/hello_world/target/debug/deps/hello_world-e22d40e86553def7.2tzygb3k5ougc0jz.rcgu.o" "-Wl,--as-needed" "-L" "/home/user/dev/rust/hello_world/target/debug/deps" "-L" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-8389830094602f5a.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-41c1085b8c701d6f.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-f733fcc57ce38b99.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr-6495ec9d4ce4f37d.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-1e3796360cca5b49.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-2e7f329b154436e1.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-1e1f5b8a84008aa8.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-cbcb223c64b13cf3.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-b40bc72e060a8196.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-1eb33ae9877d3c0f.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-0335d894dd05bed7.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-076a893ead7e7ab5.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-2e924dd85b2e9d95.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-7975ffb5e62386c4.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-285425b7cea12024.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-38694d775e998991.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-914eb40be05d8663.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-27094fcca7e14863.rlib" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-919e055b306699ae.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "/home/user/dev/rust/hello_world/target/debug/deps/hello_world-e22d40e86553def7" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-Wl,--verbose"
INFO rustc_codegen_ssa::back::link linker stderr:
If I take the 5th line, then I see, that there are variables: LC_ALL
, PATH
and VSLANG
, but after VSLANG
there is loads of other stuff and I am not sure how to treat that. Should I leave it away when writing my call to cc -m64
?
Trying that:
LC_ALL="C" PATH="/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/user/.cargo/bin:/home/hans/.config/guix/current/bin:/home/user/.config/guix/current/bin:/home/user/.config/guix/current/sbin:/home/user/.config/guix/current/bin:/home/user/.local/bin:/home/user/.guix-profile/bin:/home/user/.guix-profile/sbin:/home/user/.config/guix/current/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/user/.local/bin:/usr/lib/jvm/java-17-openjdk-amd64/bin:/usr/local/texlive/2022/bin/x86_64-linux" VSLANG="1033" cc -m64 hello_world.c
Runs, compiles a a.out
.
./a.out
Segmentation fault (core dumped)
(edited: still had my user name wrong in the variables, now replaced with the output of the variables with correct user name)
(more in separate post)
Few extra things to try chasing this down if you have the time:
* Post the binary here, maybe there are some hints in the dump as to what happened
Trying to upload the binary here on Github … "We don't support that file type." I will upload to mega again. (Or please suggest an alternative.) Here is the link.
* Is there anything unique about your hardware or setup that you can think of? (all looks pretty standard)
Not that I know of. This is a "tower" pc, not a mobile laptop. Something you put under your desk, not on your lap.
* Try an old version (`rustup install 1.56 && cargo +1.56 run`) to see if this was a regression that was introduced at some point. If this works and you have time, you could try some more versions and bisect where the regression is
rustup install 1.56 && cargo +1.56 run
info: syncing channel updates for '1.56-x86_64-unknown-linux-gnu'
info: latest update on 2021-11-01, rust version 1.56.1 (59eed8a2a 2021-11-01)
info: downloading component 'cargo'
6.2 MiB / 6.2 MiB (100 %) 2.6 MiB/s in 2s ETA: 0s
info: downloading component 'clippy'
info: downloading component 'rust-docs'
17.3 MiB / 17.3 MiB (100 %) 2.6 MiB/s in 2s ETA: 0s
info: downloading component 'rust-std'
23.5 MiB / 23.5 MiB (100 %) 2.6 MiB/s in 2s ETA: 0s
info: downloading component 'rustc'
52.9 MiB / 52.9 MiB (100 %) 16.3 MiB/s in 4s ETA: 0s
info: downloading component 'rustfmt'
3.9 MiB / 3.9 MiB (100 %) 2.6 MiB/s in 1s ETA: 0s
info: installing component 'cargo'
info: installing component 'clippy'
info: installing component 'rust-docs'
17.3 MiB / 17.3 MiB (100 %) 9.2 MiB/s in 1s ETA: 0s
info: installing component 'rust-std'
23.5 MiB / 23.5 MiB (100 %) 17.6 MiB/s in 1s ETA: 0s
info: installing component 'rustc'
52.9 MiB / 52.9 MiB (100 %) 20.0 MiB/s in 2s ETA: 0s
info: installing component 'rustfmt'
1.56-x86_64-unknown-linux-gnu installed - rustc 1.56.1 (59eed8a2a 2021-11-01)
info: checking for self-update
Compiling hello_world v0.1.0 (/home/user/dev/rust/hello_world)
Finished dev [unoptimized + debuginfo] target(s) in 0.41s
Running `target/debug/hello_world`
Segmentation fault (core dumped)
* Have you been able to compile anything at any point with Rust? Or do you know of any people with a similar setup that have run into this problem? (e.g. coworkers with the same computer & OS)
Lately I thought I would pick up Rust again and go through the Rust book again to get up to date knowledge. In the past I have used Rust, but perhaps not on this machine. Not sure whether it was already on this machine. Could also have been on another machine. Basically I merely wanted to learn again and am not sure, whether I was able to compile and run any Rust code on this machine before.
Similar setup: Not aware of any, since most of my friends are not devs and they all have other hardware.
This machine is a private machine, not my job/work machine, so no coworkers with the same hardware either.
@ZelphirKaltstahl how did you install Rust, are you emulating a classical filesystem with --emulate-fhs or something similar? I'm not sure of how the Rust toolchain work under Guix.
I am running all this on Linux Mint, no emulation I am aware of, no VM, no anything special I can see. However, I noticed, that in some of the output Rust looks inside Guix folders/directories. I am not running Guix OS. I merely have Guix as a package manager on my system ("Guix on foreign distro"), so directories of it are on the PATH
. I guess Rust should not use anything from Guix, even if it "finds" any libraries there. Perhaps that is the actual problem. I did not install Rust via Guix, so it should not interact with Guix.
Thank you for going through the effort to collect this information, the details help a lot. It seems like maybe the problem is with cc since it does the same thing - could you share cc --version -v
?
Fyi it seems like your mega link is broken fyi - the text itself is fine but it takes you to the github page on click. I have used https://paste.c-net.org/ before for sharing binaries but am not sure about its limits (mega is fine too)
From the backtrace it looks like the dynamic linker is encountering infinite recursion and therefore stackoverflowing (wtf??). But given that the C program also segfaults, this looks like an issue on your system and not a problem with Rust. Looks like something about your Guix installation is wrong. Maybe a Guix support forum/mailing list or whatever they use can help you.
Here's my theory:
From your verbose linker output and your bug report, you are using Linux Mint, but the linker being used comes from Guix you have installed on your distro.
The Guix ld is trying to link your hello_world
with host (Linux Mint) runtimes, along with glibc from Guix. It tried hard to link libraries from everywhere, thus creating hello_world
with parts from two different worlds (sort of). Here is the list of object files chosen by Guix ld, grep
'd from your verbose linker output:
I think the solution is just to gain access to a clean environment (e.g. to use the environment from Linux Mint instead of guix shell
), and use host (Linux Mint) tools to compile programs.
i am going to close this since it happens for C code too but feel free to keep discussing on the issue.
(Will try to respond to everything later.)
Thank you for going through the effort to collect this information, the details help a lot. It seems like maybe the problem is with cc since it does the same thing - could you share cc --version -v?
$ cc --version -v
Using built-in specs.
COLLECT_AS_OPTIONS='--version'
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
cc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.4.0-1ubuntu1~20.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-Av3uEd/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)
COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/9/cc1 -quiet -v -imultiarch x86_64-linux-gnu help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 -auxbase help-dummy -version --version -fasynchronous-unwind-tables -fstack-protector-strong -Wformat -Wformat-security -fstack-clash-protection -fcf-protection -o /tmp/ccgrR1JA.s
GNU C17 (Ubuntu 9.4.0-1ubuntu1~20.04.1) version 9.4.0 (x86_64-linux-gnu)
compiled by GNU C version 9.4.0, GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64'
as -v --64 --version -o /tmp/ccgWwlnz.o /tmp/ccgrR1JA.s
GNU assembler version 2.38 (x86_64-unknown-linux-gnu) using BFD version (GNU Binutils) 2.38
GNU assembler (GNU Binutils) 2.38
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-unknown-linux-gnu'.
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/home/user/.guix-profile/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/home/user/.guix-profile/lib/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/9/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/9/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper -plugin-opt=-fresolution=/tmp/cckoOYEA.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro --version /home/user/.guix-profile/lib/../lib/Scrt1.o /home/user/.guix-profile/lib/../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o -L/home/user/.guix-profile/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/9 -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/home/user/.guix-profile/lib -L/usr/lib/gcc/x86_64-linux-gnu/9/../../.. /tmp/ccgWwlnz.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/9/crtendS.o /home/user/.guix-profile/lib/../lib/crtn.o
collect2 version 9.4.0
/home/user/.guix-profile/bin/ld -plugin /usr/lib/gcc/x86_64-linux-gnu/9/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper -plugin-opt=-fresolution=/tmp/cckoOYEA.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro --version /home/user/.guix-profile/lib/../lib/Scrt1.o /home/user/.guix-profile/lib/../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o -L/home/user/.guix-profile/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/9 -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/home/user/.guix-profile/lib -L/usr/lib/gcc/x86_64-linux-gnu/9/../../.. /tmp/ccgWwlnz.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/9/crtendS.o /home/user/.guix-profile/lib/../lib/crtn.o
GNU ld (GNU Binutils) 2.38
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64'
From the backtrace it looks like the dynamic linker is encountering infinite recursion and therefore stackoverflowing (wtf??). But given that the C program also segfaults, this looks like an issue on your system and not a problem with Rust. Looks like something about your Guix installation is wrong. Maybe a Guix support forum/mailing list or whatever they use can help you.
I don't think that will help, because I have no issue using GNU Guix package manager, so they will tell me, that for Rust things I need to ask Rust community for help : ) GNU Guix package manager runs fine, so they would not see an issue with it.
I just tried using gcc
directly, which works:
$ gcc hello_world.c -o a.out
$ ./a.out
Hello World
So it must be how Rust or cc
is set up or what environment variables it uses. (correct?)
From your https://github.com/rust-lang/rust/issues/113299#issuecomment-1619166173 and your bug report, you are using Linux Mint, but the linker being used comes from Guix you have installed on your distro.
Why is this the case? Why does Rust not know what linker the actual linker is, instead of making use of the one Guix has put anywhere? Shouldn't Rust know the system's actual linker? Or are there no conventional linker locations, so that any linker found could be "the one"?
I think the solution is just to gain access to a clean environment (e.g. to use the environment from Linux Mint instead of guix shell), and use host (Linux Mint) tools to compile programs.
Yes, this seems to be the case. Not sure how to get there though. Maybe I could take Guix off the PATH
and reinstall Rust and then try again?
PATH="/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/user/.cargo/bin:/home/hans/.config/guix/current/bin:/home/user/.config/guix/current/bin:/home/user/.config/guix/current/sbin:/home/user/.config/guix/current/bin:/home/user/.local/bin:/home/user/.guix-profile/bin:/home/user/.guix-profile/sbin:/home/user/.config/guix/current/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/user/.local/bin:/usr/lib/jvm/java-17-openjdk-amd64/bin:/usr/local/texlive/2022/bin/x86_64-linux"
You definitely left Guix in your PATH.
Why does Rust not know what linker the actual linker is, instead of making use of the one Guix has put anywhere?
The default linker used by rustc is cc
. That means, a program called cc
should be present in your PATH, or you have to specify a liker during compilation, either by editing Cargo.toml
or specifying RUSTFLAGS
(-C linker=/path/to/the/linker
).
However, cc
is a C compiler, but it can help you to link objects, by calling collect2
(intermediate for ld
), collect2
then will call ld
or another linker. You can see this behavior with gcc --verbose
or for Rust, -C link-arg=--verbose
which turns on verbose output for cc
.
Plus, there's one thing to notice: when using the C compiler to link programs, cc
will add paths of GCC runtime to the list of object files. You can see this behavior with gcc --verbose
, too, as it will print out the command line arguments while invoking collect2
.
Suppose I have a very clean (i.e. without ANY environment variables, even PATH) environment, when I tell rustc to compile a program, it will fail as it can not find a linker to invoke, as in the picture below:
And if I create a symbolic link of gcc
to /tmp/bin/cc
, GCC will still complain about missing ld
:
Therefore, I think the situation is:
cc
to link hello_world
, the cc
comes from Linux Mint.cc
is a symbolic link to gcc
, which later invoked ld
to actually link the objects together. This time, the ld
comes from Guix, which exists in your PATH.libgcc_s
and Guix libraries and Guix glibc, creating hello_world
with parts from two different worlds.TL;DR Rust invoked host cc
, and host cc
invoked Giux ld
(which comes from PATH).
Shouldn't Rust know the system's actual linker? Or are there no conventional linker locations, so that any linker found could be "the one"?
On a freshly installed Guix system, with gcc-toolchain
installed, here's the linker and compiler (cc
does not exist):
cyan@apjf38heriulfh34of5 ~$ which ld
/home/cyan/.guix-profile/bin/ld
cyan@apjf38heriulfh34of5 ~$ which gcc
/home/cyan/.guix-profile/bin/gcc
For other distros with (almost) FHS compliance, they usually reside on /usr/bin/{cc,ld}
. And if we take LLVM's own linker (lld
), ld.gold
, and cross-compilation into account, then things started to get complex.
Anyway, no one can determine what linker to use, it can not be hard coded (at least no one does). For Rust, the only thing it can do is rely on PATH to get a C compiler (which can link objects). The C compiler will then try to invoke ld
.
and reinstall Rust and then try again?
You don't have to do this if your home folder is not managed by Guix.
Thanks for giving the detailed explanation about how this works in general! Lots of things I did not know.
I will try with temporarily removing Guix from my PATH
.
Actually the title of this issue was changed from my original title and now is wrong. Even though I may have Guix stuff on my PATH
, I repeat, that my OS is not GNU Guix. I am merely using Guix as a package manager "on foreign distro".
-> I suggest changing the title, so that other people will not think this is exclusively about GNU Guix OS.
Trying things with guix not on the path did not make the segfault disappear. Trying on another machine, which has GNU Guix installed as well did not result in the segfault. Not sure what to make of this.
There has to be something different in what is getting picked up, or a weird configuration with cc/gcc. I'd start by diffing the output in printenv
between the two machines and seeing what doesn't match up, and also seeing if the outputs of which cc
and which gcc
. You can also run gcc -dumpspecs
on both machines and see what is different, or try compiling your C program with -v
to see what is happening. I would focus on getting a sample C program to run successfully and then switch to Rust - maybe see if running a fresh downloaded GCC binary works? Or purging & reinstalling your system gcc?
It's good that you have a reference machine, but it's really unfortunate that you still haven't had any success. Absolute worst case you can build in a docker container, but that's a solution that shouldn't be necessary.
Thanks for the pointers.
I have set up a virtual machine with Debian 12 to test there (works). I imagine I could write code on the host system and mount a shared folder into the virtual machine (just like a volume in a docker container).
If I have any new information regarding my issue, I will post it here.
I tried this code:
I expected to see this happen:
cargo run
should printHello, world!
.Instead, this happened:
Meta
rustc --version --verbose
:cargo --version
:lsb_release -a
uname -a
gcc --version
Rust was installed via
rustup
, installed viacurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
on 2023-07-03.Backtrace
``` Finished dev [unoptimized + debuginfo] target(s) in 0.00s ```
What I already tried