LDFLAGS appended to CFLAGS causing build failures

[mjeveritt]

I'm experiencing some strange build failures with musl libc, which @anarchpenguin and I have narrowed down to LDFLAGS becoming appended to CFLAGS in builds. Should this really happen, and is there an option to prevent it, if so, for circumstances where it should not ..

[vaeth]

Yes, this is intentional (e.g. for -flto or for "small" packages which need no separate compile and linking phase).

You can prevent it by setting NOLDADD=1, either globally or on a per-package base in package.cflags

[mjeveritt]

Does this not also affect src_install phase too?

[vaeth]

I am not sure whether I understand the question.
The *FLAGS are the same for all phases; it is up to the build system to deal with them differently in different phases. NOLDADD is used only by portage-bashrc-mv.

[anarchpenguin]

Yes, this is intentional (e.g. for -flto or for "small" packages which need no separate compile and linking phase).

You can prevent it by setting NOLDADD=1, either globally or on a per-package base in package.cflags

umm ldflags should never be added to CFLAGS, not even for lto builds. You add CFLAGS to LDFLAGS to achieve the results that you are thinking of.

[vaeth]

For correctly working build systems you are right. However, there were several examples of ebuilds/build systems which didn't honour LDFLAGS at all. The latter may even be a security issue if you use flags like -Wl,-z,now -Wl,-z,relro

[mjeveritt]

Surely in this case, it's better to highlight and fix bad ebuilds than cause random breakage elsewhere?!

It should be possible to create a tracker bug for the issue, and highlight maintainers in individual bugs, and/or a combined bug for maintainer-needed.

[anarchpenguin]

Surely in this case, it's better to highlight and fix bad ebuilds than cause random breakage elsewhere?!

It should be possible to create a tracker bug for the issue, and highlight maintainers in individual bugs, and/or a combined bug for maintainer-needed.

The breakage is due to use using the features incorrectly has nothing to do with an actual problem in the build system or the toolchain. You should fix your script rather then expect the toolchain or packages to adjust to what you want to believe is correct.

[anarchpenguin]

For correctly working build systems you are right. However, there were several examples of ebuilds/build systems which didn't honour LDFLAGS at all. The latter may even be a security issue if you use flags like -Wl,-z,now -Wl,-z,relro

If you have found packages in the tree with such behavior you should have opened a bug report, these packages should be fixed to respect the build system the user has defined when plausible.

[vaeth]

you should have opened a bug report

In an ideal world, all packages behave the same concerning *FLAGS or are fixed, soon, and then later won't ever break again. In the real world, however, you have the choice between running a more secure system or having a dream of an ideal world.
If you read carefully every log of every package you compile, you are free to switch off the feature globally. I prefer to have it on globally and only switch it off for the few packages which have troubles if LDFLAGS are used already for compilation.
In any case, it is configurable, and I do not intend to change the default.