net-ftp/filezilla needs ltofat.conf

[rx80]

No description provided.

[darkbasic]

Just for curiosity, which one is the policy for contributions? I know you use latest GCC 7.2, but if a contributor uses an older version of gcc he might need overrides which are not needed with latest version of gcc. How do you plan to manage this?

[InBetweenNames]

Great question--I think it's reasonable to expect users to be using a GCC in the latest series (7.x) with a reasonably new binutils. I use:

GCC 7.2.0
Binutils 2.29 (ld.gold)

Since LTO is handled through a linker plugin, I'm not sure if the binutils version matters too much.
I wouldn't expect users of older versions of gcc to be super interested in an LTOed system as it is very much a feature that will introduce breakage in the system. However, if this is something that is desired, we could perhaps have comments for PRs that use older GCCs and are having problems that are not present on a newer GCC. For the record, I'm able to emerge -e world my system with GCC 7.2.0.

As for this PR, first, thank you for the submission! I actually just tested this out locally and it turns out I didn't need an ltofat override for it. I'm curious, which GCC version and binutils you are using? Also, did you emerge -e world when you first enabled LTO on your system?

[rx80]

I'm on GCC 7.2.0 and binutils 2.28.1. Although i didn't emerge -e @world for full lto. If that can be the problem, i'll do that step first.

[Althorion]

There are some inconsistencies about which packages would build with LTO. For example, you seem to be able to build app-editors/vim just fine, when I needed to add ltofat.conf. I suspect this might be either because of different sys-devel/binutils version (2.28.1) or different -march (bdver2). This is actually a reason why I’m not making a pull request with my changes—I already did a full emerge -e @world.

BTW, what is the order of preference for envs? In particular, is nolto.conf prefered over ltonographite.conf?

[InBetweenNames]

Would you mind doing that? I'll leave the PR open here--I just want to control for all factors first. Perhaps I should even update the readme to recommend users do an emerge -e @world first. I'll try binutils 2.28.1 myself to see if I can repro this with that in mind.

The -march options and -O* shouldn't affect the link-time stuff with resolving symbols, but maybe the binutils version matters more than I realized. I would say the order of preference in the configs is as follows:

• No overrides necessary
• LTO with fat objects (ltofat)
• Configurations without graphite (ltonographite)
• Configurations without LTO (nolto)

The rest of the configurations tend to fit in between those

[rx80]

@InBetweenNames no need to do any further tests. The problem was somewhere else entirely. I was switching around gcc versions earlier and forgot to update the linker plugin symlink at /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/liblto_plugin.so. Maybe that could be a part of the readme file so people don't forget..

/usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/liblto_plugin.so
has to be a symlink to
/usr/libexec/gcc/x86_64-pc-linux-gnu/7.2.0/liblto_plugin.so
Or whatever the current active gcc version is

[InBetweenNames]

Wow! I completely forgot I even did that--good catch!! Do you want to submit a PR to update the README for that? I'd prefer for people to be recognized for their contributions, and no doubt people will run into this problem.

@Althorion have you tried what @rx80 has suggested?

[darkbasic]

Yes I think we definitely need an exaustive guide in the README with all the steps needed in order to avoid problems (including @world rebuilds etc), otherwise handling PRs will be a nightmare.

[Althorion]

Not yet, I won’t have time to do that today I’m afraid, but I’ll try that tomorrow and will issue a PR if needed.

[InBetweenNames]

Sounds good! I'm closing this PR since this particular case has been solved, but please open a new issue if the problem persists for you after trying the fix mentioned--that means we've got something else to investigate here.