Cargo build fails due to -flto

[MagaTailor]

Trying to build the latest cargo master fails at link time due to -flto being present in CFLAGS resulting in 'undefined reference' errors.

Unsetting the flags allows to finish the optimized build. Encountered on 32 bit Linux, i686 and gcc 4.9.2 - didn't check if using -ffat-lto-objects helps.

[alexcrichton]

Thanks for the report! Could you provide the steps I need to reproduce this? I tried locally and was unable to by setting CFLAGS=-flto

[MagaTailor]

Are you saying other flags could have been at fault? I was guessing about lto due to the link errors, however I deliberately wrote about unsetting all flags as I also had (-O3 -march=athlon-xp -fipa-pta). Ditto for CXXFLAGS.

The rustc I was using generates pentium2 code by default.

[MagaTailor]

Nope, my guess was right, this one flag is enough to trigger the failure. Cargo was configured with --disable-debug --enable-optimize and using local rust/cargo binaries.
Could be a gcc 4.9 bug of course.

https://gist.github.com/petevine/e43745e50b5792521927

[alexcrichton]

Hm it could be the case that -flto needs to be passed to the final linker invocation as well? I'm not entirely sure how LTO works in the world-of-C at least.

Oddly enough for me on gcc 4.8.4 doing CFLAGS=-flto cargo build inside of this repo seems to work out. Could you try to re-run the final linker command with -flto and see if that changes things?

[MagaTailor]

I'll try that - could you tell me if there's any static linking involved? Cause then ar, nm, ranlib have to be invoked as gcc-ar, etc. when doing lto (normally configurable via Makefiles). In that case your setup might simply be doing this automatically.

EDIT:
After adding -C link-args=-flto to the final rustc command line there was no difference at all.

I was using ./configure followed by make and not cargo build (probably no difference)

[MagaTailor]

After adding -ffat-lto-objects linking is completed successfully. So it was probably about static libs after all.

[alexcrichton]

Ah yeah if you're required to use gcc-ar then that'd probably be what went wrong, we use LLVM's bundled ar implementation wherever possible, which means that it probably isn't compatible.