link error with undefined reference to `main' on Arch

[clux]

I tried running an internal project through tarpaulin today and it appears to fail in the link stage. I'm not really sure what's going on here, but it does work inside an ubuntu xenial docker container on the same project (running docker in --privileged mode to work around ASLR errors from lacking EPERM), so I'm guessing it's something to do with gcc7.

Here is the output after all the Compiling lines:

   Compiling indicatif v0.3.3
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/clux/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/clux/sqbu/lal/target/debug/deps/serde_derive-0c82b8e5158c5e10.0.o" "-o" "/home/clux/sqbu/lal/target/debug/deps/libserde_derive-0c82b8e5158c5e10.so" "/home/clux/sqbu/lal/target/debug/deps/serde_derive-0c82b8e5158c5e10.crate.metadata.o" "-nodefaultlibs" "-L" "/home/clux/sqbu/lal/target/debug/deps" "-L" "/home/clux/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/clux/sqbu/lal/target/debug/deps/libserde_codegen_internals-d56dd4dc3a22cef8.rlib" "/home/clux/sqbu/lal/target/debug/deps/libsyn-593a087ca2571565.rlib" "/home/clux/sqbu/lal/target/debug/deps/libsynom-1fddc0802262e2b9.rlib" "/home/clux/sqbu/lal/target/debug/deps/libquote-565e17019bbf404d.rlib" "/home/clux/sqbu/lal/target/debug/deps/libunicode_xid-0718538d6479f922.rlib" "-L" "/home/clux/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bdynamic" "-l" "proc_macro-21659b2d231fd6e3" "-L" "/home/clux/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-l" "syntax-93b867817c21b413" "-L" "/home/clux/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-l" "rustc_data_structures-7c7ac4ebfcbb1807" "-L" "/home/clux/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-l" "rustc_errors-8975c93dcf60bb3d" "-L" "/home/clux/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-l" "syntax_pos-364f7f3b054e6796" "-L" "/home/clux/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-l" "serialize-204d1e77b99bcb91" "-L" "/home/clux/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-l" "term-4959b4e709084e0a" "-L" "/home/clux/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-l" "std-35ad9950c7e5074b" "-Wl,-Bstatic" "/home/clux/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-863b57a66ba6c3e1.rlib" "-Wl,-Bdynamic" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util" "-shared" "-no-pie"
  = note: /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/crt1.o: In function `_start':
          (.text+0x20): undefined reference to `main'
          collect2: error: ld returned 1 exit status
          

error: aborting due to previous error(s)

error: Could not compile `serde_derive`.
Build failed, waiting for other jobs to finish...

system:

$ uname -a
Linux kjttks 4.12.3-1-ARCH #1 SMP PREEMPT Sat Jul 22 15:32:02 UTC 2017 x86_64 GNU/Linux
$ rustc --version
rustc 1.19.0 (0ade33941 2017-07-17)
$ cargo tarpaulin --version
cargo-tarpaulin version: 0.3.9
$ cc -Q -v
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.1.1 20170630 (GCC) 

[xd009642]

Hmm no ideas off the top of my head, I'll look into it. Unless @yodaldevoid has any thoughts

[yodaldevoid]

Solve one linker problem and you become an expert...

I kid of course.

Of the top of my head I can't think of any reason why this would fail like this. What version of gcc were you using with your Xenial container?

[xd009642]

You raise a linker issue and you solve another, think that makes you the resident expert ;)

[yodaldevoid]

Well, I more or less caused the second, so...

[clux]

The container I was using was that succeeded muslrust so I guess musl-gcc 5.4.0, but that's probably not very helpful. I can see if I can bisect a bit on my problematic package, it seems most things I have actually work on my system with tarpaulin, just the big project fails to link like this.

[xd009642]

I don't suppose the project in question is on github or gitlab so I can try it out myself? If that's not possible a minimal project that recreates the same issue that you can share would be helpful. I'm also wondering if it has any relation to rust-lang/rust#41416

[clux]

Bad news is that I can't share it, but good news is that I've identified a crate that causes the failure; serde_derive at 0.9.15 that was in my Cargo.toml.

A simple lib.rs with:

#[macro_use]
extern crate serde_derive;

#[cfg(test)]
mod tests {
  #[test]
  fn blah() {
    assert_eq!(true, true, "testing");
  }
}

Will fail in the manner above. I tried updating serde_derive as well, but still no luck.

cargo list --tree
└── serde_derive (1.0.11)
    ├── quote (0.3.15)
    ├── serde_derive_internals (0.15.1)
    │   ├── syn (0.11.11)
    │   │   ├── quote (0.3.15)
    │   │   ├── synom (0.11.3)
    │   │   │   └── unicode-xid (0.0.4)
    │   │   └── unicode-xid (0.0.4)
    │   └── synom (0.11.3)
    │       └── unicode-xid (0.0.4)
    └── syn (0.11.11)
        ├── quote (0.3.15)
        ├── synom (0.11.3)
        │   └── unicode-xid (0.0.4)
        └── unicode-xid (0.0.4)

[yodaldevoid]

Gotta love minimal test cases. Thank you!

[yodaldevoid]

I have reproduced the error with your minimal test case using GCC 6.3.0 on Ubuntu so it doesn't seem to be tied to Arch or GCC 7.

$ uname -a
Linux auroria 4.12.0-041200rc2-generic #201705212331 SMP Mon May 22 03:32:26 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.3.0-12ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --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 --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --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-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2) 

[yodaldevoid]

```
error: /home/yodal/testy_mctestface/target/debug/deps/libserde_derive-1af48270eaa37e29.so: cannot dynamically load executable
 --> src/lib.rs:2:1
  |
2 | extern crate serde_derive;
```

I don't know much about custom derive other than it is magic in code form so I can't say at the moment whether this is because of custom derive or specific to `serde_derive`. I guess it would be worth it to test other custom derive crates.

Side note: it seems we really should be using `link-arg` as `link-args` only uses the last set of values given causing previously set `link-args` to be ignored.

Edit: Ok, I don't know what I was thinking, but I obviously need to stop working on this stuff in the middle of the night.

What I think is really is going on here is `serde_derive` really doesn't like `-no-pie` (why does it always have to come back to this). This can be seen by compiling the the minimal test case with `RUSTFLAGS="-C link-arg=-no-pie"` stapled to the front. Now, one theory I have is that `serde_derive` (and maybe custom derive in general, but that needs to be tested) is going behind our back during code generation and creating code with PIC or PIE hence why it cannot be linked in when passed `-nostartfiles`.

[xd009642]

Now if we could apply no-pie to only the project and subprojects instead of dependencies that could solve it.. I figure I'm right in this is down to proc-macros having to be dynamically linked? https://github.com/rust-lang/rfcs/blob/master/text/1566-proc-macros.md

UPDATE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464 looks like it's this same error! serde_derive generates an so... Looking for a potential resolution now

[xd009642]

Looking into revisiting this, this week. Was there a linker based issue in rustc related to this? I seem to remember seeing something but can't find it again for the life of me

[lnicola]

Was there a linker based issue in rustc related to this? I seem to remember seeing something but can't find it again for the life of me

Maybe rust-lang/rust#43486, although it's unrelated?

Anyway, according to the GCC bug you linked, it's about having -shared -no-pie in the command line. If you reverse the order it works just fine. I tested it.