Build fails with LTO about rtorrent HOT 8 OPEN

Correct me if I'm misunderstanding, but utils/directory.h:46:8: and input/./../utils/directory.h:46:8 are the exact same file, so it sounds like whatever build system gentoo is using is generating duplicate definitions for itself in the libsub_*.a files. Using the documented build process with -Werror=odr compiles perfectly fine for me.

I doubt rTorrent will ever officially support gentoo's build system, but even if I wanted to help unofficially, there's not any information on how to reproduce.

from rtorrent.

Correct me if I'm misunderstanding, but utils/directory.h:46:8: and input/./../utils/directory.h:46:8 are the exact same file, so it sounds like whatever build system gentoo is using is generating duplicate definitions for itself in the libsub_*.a files. Using the documented build process with -Werror=odr compiles perfectly fine for me.

I doubt rTorrent will ever officially support gentoo's build system, but even if I wanted to help unofficially, there's not any information on how to reproduce.

The best way to reproduce would be to open the attachment titled "full logs" and check for information on how to reproduce.

In short, Gentoo is not using an alternative build system, there's nothing specific to Gentoo here.

It's just running configure and make.

I would be happy to provide any additional details needed but if we can't agree on whether or not the official configure and make scripts were used then I'm not sure how much anything I say matters.

from rtorrent.

So there's no set of emerge commands I could run to quickly reproduce on a gentoo docker image or anything? I spent some time looking at the log, and tried docker run gentoo/stage3 "emerge --sync && emerge '=net-p2p/rtorrent-0.9.8-r2::gentoo'", but didn't get any error. Trying to adapt the configure command to my system would be possible but also seems pretty tedious (not to mention trying to match toolset versions), so if there's an easier way it would be greatly appreciated.

from rtorrent.

In the Gentoo container, if you add these flags to /etc/portage/make.conf as part of CFLAGS / CXXFLAGS / LDFLAGS, it should demonstrate the issue:

-flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing

Note: -flto is needed to produce LTO code generation, and the -Werror=* flags cause the link-time "lto-wrapper" based codegen to fatally error when safety constraints are violated.

In principle it should reproduce with a plain configure and make, when using those flags. I hastily tried that with rtorrent from a git clone, but it didn't appear to compile due to libtorrent version differences and I didn't have time right then to chase that down.

"Probably", using those flags on your own system with your own toolset versions and whatever configure command you usually use, would be enough too.

from rtorrent.

I gave it enough of an effort to ensure that it's really LTO shenanigans at play, rather than a true ODR violation. It doesn't seem insurmountable, so maybe I'll take another shot later, but all the solutions I found didn't seem to be worth the increase in complexity.

from rtorrent.