Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we use the "lto" USE flag for packages which have it? #203

Open
mateuszmandera opened this issue Nov 22, 2018 · 5 comments
Open

Should we use the "lto" USE flag for packages which have it? #203

mateuszmandera opened this issue Nov 22, 2018 · 5 comments

Comments

@mateuszmandera
Copy link

mateuszmandera commented Nov 22, 2018

What's the approach for the lto USE flag? Does it conflict with our own lto settings?

@ionenwks
Copy link

ionenwks commented Nov 22, 2018

That flag usually exist when the configure script has a --enable-lto of some kind implying it's developer-tested/approved. Sometimes it just add -flto which changes nothing, but some other times it has workarounds and may disable LTO in some parts to deal with them.

If you don't like the latter (and also blocking flag-o-matic), you may want to avoid it, but otherwise you should use it to avoid build/runtime issues. Some packages like Firefox will sort extra requirements like enabling gold linker.

On another note, ffmpeg sure could use having this flag available for clarity. The way the ebuild handles it right now can lead to issues given it auto-enables the option if you have -flto but doesn't strip it.. and even if it tried, some of us block that (for now, don't have -flto in CFLAGS and set EXTRA_FFMPEG_CONF="--enable-lto". The overlay here just disable LTO at the moment.)

@InBetweenNames
Copy link
Owner

I think we should use the lto flag if it exists for sure. It shouldn't conflict with anything locally, unless you have override-flagomatic enabled. If you have that flag enabled, then I could see conflicts arising for the cases @ionenwks mentioned. In the cases where it's problematic, you could just set LTO_ENABLE_FLAGOMATIC=yes and it should allow it to work once again.

@mateuszmandera
Copy link
Author

I dont have build.log for these right now, I'll try to post them later, but i was unable to compile dev-util/electron neither with our flags nor the package's lto flag. With the flag gcc was throwing an error about "-fuse-ld lld" being an invalid option. I changed the compiler for the package to clang,which supports the lld linker, but it failed with another error much later into the building process.

I will post the build.log for these various cases soon.

@InBetweenNames
Copy link
Owner

Yeah lld is not supported by GCC yet. There's talk of supporting it in the future. I see this as being more of a tooling issue than an LTO issue right now, and possibly an ebuild bug.

@mateuszmandera
Copy link
Author

Yeah the lld issue doesn't require uploading the build.log here, I guess. Building with clang fails with lld throwing undefined symbol errors very late into the building process. Perhaps this is more relevant for the gentoo bugzilla, but I'll post this here too in case someone wants to take a look.

Well, build.log is 70MB so github won't let me upload it, it crashes at the point i posted here: https://pastebin.com/LkacyFeE

Should I find a way to make the full build.log available here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants