search

rumpkernel / rumprun-packages

Ready-made packages of software for running on the Rumprun unikernel
Other
202 stars 80 forks source link

Linker error when building my rust application #138

Open ghost opened 7 years ago

ghost commented 7 years ago

I have the following linker error when I want to build my rust application (which works on Linux and MacOS) on rumprun-hw:

error: linking with `x86_64-rumprun-netbsd-gcc` failed: exit code: 1
  |
  = note: "x86_64-rumprun-netbsd-gcc" "-Wl,--as-needed" .... "-l" "util" "-l" "pthread" "-l" "unwind" "-l" "m" "-l" "util"

  = note: /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail ../../bfd/elflink.c:8051
          collect2: error: ld returned 1 exit status

error: aborting due to previous error

error: Could not compile `Zebu_tester`.

Caused by:
  process didn't exit successfully: `rustc --crate-name .... /target/x86_64-rumprun-netbsd/debug/build/gc-54f86e86d78902e9/out` (exit code: 101)

I've seen the same error (all pointing to elflink.c, but different lines) on both Ubuntu 14.04 and 16.04, using GCC4.8, 4.8, 5.4 and 6, and binutils 2.24, 2.25, 2.26.1 and 2.28. Just binutils 2.28 points to a relevant line in elflink.c with an assersion in it. This is the assertion which fails on 2.26.1:bfd/elflink.c:8300 and 2.28:bfd/elflink.c:8462:

      BFD_ASSERT ((*rel_hash)->indx >= 0);
gandro commented 7 years ago

If I recall correctly (but I might be wrong, it's been a while since I hacked on this) this assertion is triggered by Rust passing -l"c" twice to the x86_64-rumprun-netbsd-gcc linker. I never quite managed to figure out why this triggers an assertion failure, as it only seems to happen in combination with Rust.

It can happen that -lc is passed twice if you are using a Rust FFI library that contains #[link(name = "c")], which is true for ancient versions of Rusts libc crate. Could you check that this is the case, or perhaps share the full output of the failed linker invocation?

ghost commented 7 years ago

This is the full command which causes the assertion failure:

error: linking with `x86_64-rumprun-netbsd-gcc` failed: exit code: 1
  |
  = note: "x86_64-rumprun-netbsd-gcc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/javad/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-rumprun-netbsd/lib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/Zebu_tester-18ae0efc0aa0beb1.0.o" "-o" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/Zebu_tester-18ae0efc0aa0beb1" "-Wl,--gc-sections" "-L" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps" "-L" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/debug/deps" "-L" "/home/javad/seL4/rumprun-sel4-dempapp_3/build2/x86_64/rumprun/rumprun-x86_64/lib/" "-L" "/home/javad/seL4/rumprun-sel4-dempapp_3/build2/x86_64/rumprun/rumprun-x86_64/lib/rumprun-sel4/" "-L" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/build/mu-01d898f049b2d32a/out" "-L" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/build/mu-01d898f049b2d32a/out" "-L" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/build/gc-5ee022e03eb070f2/out" "-L" "/home/javad/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-rumprun-netbsd/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libtester-00e18903182e1077.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libmu-4cd0e6787258ec19.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/liblibloading-c41a2f71457b39f3.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libdocopt-5ef8f439428b13b0.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libstrsim-026a04a7e1ede61c.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/liblazy_static-82c2efae9a7bf732.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libmaplit-6a79cadceeca5cb0.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libstderrlog-40318da8932c09b1.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libast-b3a7647edf8345da.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libregex-bf57a839db75dbae.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libregex_syntax-8b74a2985735b213.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libaho_corasick-c795bbd3a96f4a35.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libmemchr-4c3682d5f0e14581.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libthread_local-a561abce7ea185f1.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libthread_id-e41c347f28e6505f.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libutf8_ranges-142806e76d52d8c6.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libpetgraph-cb19a66416e2f20c.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libordermap-2bde98eb47fe8c07.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libfixedbitset-069dd3bfb844d9ac.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libgc-547de357f7e56ced.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libfield_offset-7a205f2031a6e3c3.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libcrossbeam-520d8a01e7456c39.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libaligned_alloc-9dc50e3716607a7d.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libwinapi-a5898d7aceb63fac.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libsimple_logger-970050de0bc5d7f1.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libtime-cd5e3a346d1a17b6.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/liblog-d4c0e5c2504fbbea.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/liblazy_static-623b7da40b68c83f.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libutils-9fa383b52f218999.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libmemsec-65a6e81ac36cb839.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/librand-c9d9fbdab2355ee4.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libmemmap-e6f8e937442d0733.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/liblibc-5dc7b85e748840b4.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/librustc_serialize-54d2bf33b1d4b0b0.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libbyteorder-fab4d718c73e8b35.rlib" "/home/javad/seL4/rumprun-sel4-dempapp_3/apps/Zebu_tester/target/x86_64-rumprun-netbsd/debug/deps/libkernel32-835ed4d4f4dc2d3e.rlib" "/home/javad/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-rumprun-netbsd/lib/libstd-9a66b6a343d52844.rlib" "/home/javad/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-rumprun-netbsd/lib/librand-6bc49e032a89c77d.rlib" "/home/javad/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-rumprun-netbsd/lib/libcollections-a2a467c3ca3b6479.rlib" "/home/javad/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-rumprun-netbsd/lib/libstd_unicode-e54225ff8f33e08f.rlib" "/home/javad/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-rumprun-netbsd/lib/libpanic_unwind-9d79f761aa668a33.rlib" "/home/javad/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-rumprun-netbsd/lib/libunwind-2beb731af7a6faec.rlib" "/home/javad/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-rumprun-netbsd/lib/liballoc-ce7b9706e1719f27.rlib" "/home/javad/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-rumprun-netbsd/lib/liballoc_system-5636d8d1255715e9.rlib" "/home/javad/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-rumprun-netbsd/lib/liblibc-95af4192ed69a1c8.rlib" "/home/javad/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-rumprun-netbsd/lib/libcore-cd0ca85e71f914ca.rlib" "/home/javad/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-rumprun-netbsd/lib/libcompiler_builtins-0bf24067248742a8.rlib" "-l" "util" "-l" "pthread" "-l" "unwind" "-l" "m" "-l" "util"
  = note: /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.26.1 assertion fail ../../bfd/elflink.c:8315
          collect2: error: ld returned 1 exit status

error: aborting due to previous error

I've not used #[link(name = "c")] explicitly in my application.

ghost commented 7 years ago

I re-arranged my source code and now the error is changed to this:

  = note: /home/javad/rumprun/rust_tester/target/x86_64-rumprun-netbsd/debug/deps/libtime-cd5e3a346d1a17b6.rlib(time-cd5e3a346d1a17b6.0.o): In function `time::tzset':
          /home/javad/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.1.36/src/lib.rs:287: warning: warning: reference to compatibility tzset(); include <time.h> for correct reference
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          /home/javad/tools/binutils-2.25/toolchain/bin/ld: BFD (GNU Binutils) 2.25 assertion fail elflink.c:8015
          collect2: error: ld returned 1 exit status

error: aborting due to previous error

error: Could not compile `rust_tester`.
ghost commented 7 years ago

Exactly the same application on different toolchain versions (gcc5.4 and binutils 2.26.1) produce the following error:

!!!
!!! NOTE: rumprun-bake is experimental. syntax may change in the future
!!!

/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(initfini.o): In function `___dlauxinfo':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/misc/initfini.c:66: multiple definition of `___dlauxinfo'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x19640): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(_env.o): In function `__envvarnamelen':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/stdlib/_env.c:133: multiple definition of `__envvarnamelen'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x5960): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(_env.o): In function `__freeenvvar':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/stdlib/_env.c:160: multiple definition of `__freeenvvar'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x59c0): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(_env.o): In function `__allocenvvar':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/stdlib/_env.c:174: multiple definition of `__allocenvvar'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x5a20): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(_env.o): In function `__canoverwriteenvvar':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/stdlib/_env.c:195: multiple definition of `__canoverwriteenvvar'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x5a70): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(_env.o): In function `__getenvslot':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/stdlib/_env.c:254: multiple definition of `__getenvslot'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x5ae0): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(_env.o): In function `__findenvvar':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/stdlib/_env.c:329: multiple definition of `__findenvvar'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x5c80): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(_env.o): In function `__findenv':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/stdlib/_env.c:339: multiple definition of `__findenv'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x5cb0): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(_env.o): In function `__readlockenv':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/stdlib/_env.c:360: multiple definition of `__readlockenv'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x5d10): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(_env.o): In function `__writelockenv':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/stdlib/_env.c:374: multiple definition of `__writelockenv'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x5d40): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(_env.o): In function `__unlockenv':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/stdlib/_env.c:388: multiple definition of `__unlockenv'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x5d70): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(atexit.o): In function `__cxa_atexit':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/stdlib/atexit.c:154: multiple definition of `__cxa_atexit'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x13d10): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(atexit.o): In function `__cxa_finalize':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/stdlib/atexit.c:185: multiple definition of `__cxa_finalize'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x13df0): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(atexit.o): In function `atexit':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/stdlib/atexit.c:258: multiple definition of `atexit'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x13f00): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(stack_protector.o): In function `__stack_chk_fail':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/misc/stack_protector.c:109: multiple definition of `__stack_chk_fail'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x14310): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(stack_protector.o): In function `__chk_fail':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/misc/stack_protector.c:115: multiple definition of `__chk_fail'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x14320): first defined here
/home/javad/rumprun/rumprun/./rumprun/rumprun-x86_64/lib/rumprun-hw/libc.a(stack_protector.o): In function `__stack_chk_fail_local':
/home/javad/rumprun/rumprun/src-netbsd/lib/libc/misc/stack_protector.c:121: multiple definition of `__stack_chk_fail_local'
/tmp/rumprun-bake.wfTZkr/tmp1.obj:(.text+0x14330): first defined here
/usr/bin/ld: rust_tester.bin: section .tbss lma 0x86c2e8 adjusted to 0x86c2f0
collect2: error: ld returned 1 exit status
gandro commented 7 years ago

That's interesting. Could indicate that the assertions were also triggered by these conflicts. I'm wondering though how the conflicts can occur in the first place.

anttikantee commented 7 years ago

If I'm guessing correctly, the conflicts are probably occurring because: 1) rust is explicitly linking with -lc when it's creating the pre-baked object 2) using an ld -r object for the intermediate pre-baked object is atrocious

Fixing "2" is anything but easy (at least AFAIK), but fixing "1" alone might do the trick.

I'm all for someone fixing "2" ;-)

gandro commented 7 years ago

Good point. The Rust standard library (as well as their libc bindings) have long been patched not to explicitly request -lc when compiling for Rumprun. But this does not stop other Rust libraries from doing that if they want to use some C functions not part of the official C bindings. After some playing around I can now reproduce the issue with the following minimum example. foo is a Rust library that explicitly requests the Rust compiler to pass -lc when building libfoo.rlib.

$ cat foo.rs 
#[link(name = "c")]
extern {} // normally we would declare some function signatures here
$ rustc --crate-type lib --target x86_64-rumprun-netbsd foo.rs
$ cat bar.rs 
extern crate foo;
fn main() {}
$ rustc -L . --target x86_64-rumprun-netbsd bar.rs     
error: linking with `x86_64-rumprun-netbsd-gcc` failed: exit code: 1
[same error as above]

I fully agree that fixing "2" would be the right thing to do :) If I manage to allocate some free time, I might take a stab at it (or at least get a better understanding of the issue), but no promises!

In the mean time, it seems to me the workaround is to avoid passing -lc when "fermenting" libraries.

@javadebrahimian Do you see if any of the crates your project use something like #[link(name = "c")]? Some crates might also explicitly pass -lc in their build script (build.rs). Could you try to see if getting rid of these makes it compile? Thanks!

Currently unclear to me is if libc is a special case here, of if this can happen with any library. If libc is a special case, perhaps we could hack around this in app-tools (as a workaround), and manually strip any superfluous -lcs?

ghost commented 7 years ago

I looked at all of the crates in my cargo registry and non of them explicitly use #[link(name = "c")] or do it in build.rs for netbsd. There were a few extern functions which used #[link(name = "c")] in my application, which I replaced with empty functions to see if it causes the error, but that didn't change the error.

ghost commented 7 years ago

A new observation: This main() builds and works:

fn main(){
    test_exhaust_alloc();
}

But this one produces linker assertion failure as mentioned before:

fn main(){
    test_add_simple();
}

And this one builds and works:

fn main(){
    test_exhaust_alloc();
    test_add_simple();
}

Seems weird to me. I'm not sure what's happening, but I have one hypothesis: the second test function (test_add_simple();) is using 'libloading' crate. When I looked at build.rs of this crate, I guessed the following code may cause the problem:

fn main(){
    let target = TargetInfo::new().expect("could not get target info");
    match target.target_os() {
        "linux" | "android" => println!("cargo:rustc-link-lib=dl"),
        "freebsd" | "dragonfly" => println!("cargo:rustc-link-lib=c"),
        // netbsd claims dl* will be available to any dynamically linked binary, but I haven’t
        // found any libraries that have to be linked to on other platforms.
        // What happens if the executable is not linked up dynamically?
        "openbsd" | "bitrig" | "netbsd" | "macos" | "ios" => {}
        // dependencies come with winapi
        "windows" => {}
        tos => {
            writeln!(::std::io::stderr(),
                     "Building for an unknown target_os=`{}`!\nPlease report an issue ",
                     tos).expect("could not report the error");
            ::std::process::exit(0xfc);
        }
    }
    maybe_test_helpers();
}

To be more specific, the line "openbsd" | "bitrig" | "netbsd" | "macos" | "ios" => {} is not linking against anything for netbsd. So maybe when I use it alone, the linker doesn't know what to do, but when I use it with another function which includes linking instructions (inside the libraries it uses), then the linker problem is solved.

As I said I'm not sure about it, so please let me know if you have any ideas about it.

gandro commented 7 years ago

Thanks for the update, I might take a closer look later this week. I just wanted to post a heads up that Rumprun does not support dynamic linking, so any crate that depends on libloading will most likely be broken. :/

ghost commented 7 years ago

I can confirm that the error came from using the libloading crate. By replacing the used functions with my own ones, the linker does not fail anymore.