Can you add documentation for bugs/cases that necessitate "LDADD/CADD"?

[jiblime]

Hello, thank you for the amazing tool. I've been extending its usage for myself and am going through the documentation to better understand it.

Regarding NOCADD:

NOCADD:
For -flto, it is necessary to add CFLAGS and CXXFLAGS to LDFLAGS.
In rare circumstances, this can cause trouble, so we allow optionally
to deactivate this feature.

Can you link bug reports or name packages that cause this to be a necessity? I would like to understand the problem more, and see if it is still a requirement.

I have tested NOCADD=1 emerge -1 dev-qt/qtsql and while it was configured with LDFLAGS='-Wl,-O1 -Wl,--as-needed', emerge --info dev-qt/qtsql actually does not show LDFLAGS having been set for the process (although this remedied itself with the LDFLAGS having been appended to *FLAGS).

Is this an -flto specific problem?

As an aside, does the ReplaceFlags function only apply to user set *FLAGS, or is there a way to make it replace all flags during compilation, similar to how the flag-o-matic.eclass works?

[vaeth]

What emerge --info shows for a package should coincide with what emerge displays at the beginning of the package: This should be already the merged state (taking NOCADD into account). If you do not use -flto* (in CFLAGS, CXXFLAGS, or LDFLAGS) then NOCADD=1 is assumed “automatically”. For this reason, I actually never had a case where I had to set NOCADD manually.

Since some init system (most notably new versions of meson) do the job of of NOCADD=0/NOLDADD=0 and complain if you do it manually, it was necessary to have ways to avoid it. In https://github.com/vaeth/portage-env-mv/blob/master/package.cflags/no-add you find files which at some time broke without NOLDADD/MESONDEDUP with my *FLAGS settings. I do not test very regularly whether these flags are still necessary.