A lot "does not respect CFLAGS in linking command" bugs were filed lately, i suspect that many of them are invalid. QA team, please clarify and document which *FLAGS, in which cases and why should be added to linker commands.
(In reply to Nikoli from comment #0) > i suspect that many of them are invalid why? did you not understand the reasoning given be the toolchain people?
gnu docs say: > "CFLAGS should be used in every invocation of the C compiler, both those > which do compilation and those which do linking." diego (the old QA team leader) said: > It is not bad indeed. Some of the flags, such as -fopenmp, are needed in > both stages. It's extremely common for build systems to use them for both. toolchain said: bug 446281 so why does this bug block anything? It's a small improvement, but it is an improvement.
> > i suspect that many of them are invalid > why? Because portage does not do LDFLAGS="$CFLAGS $LDFLAGS". > did you not understand the reasoning given be the toolchain people? Documentation must be in proper format, some discussion in random bug report can not be counted as valid documentation. > so why does this bug block anything? It's a small improvement, but it is an improvement. Because it requires editing a lot ebuilds, changing upstream build systems and explaining upstreams why exactly these changes are required.
(In reply to Nikoli from comment #3) > > > i suspect that many of them are invalid > > why? > > Because portage does not do LDFLAGS="$CFLAGS $LDFLAGS". > Because that would be terrible hackery. > > did you not understand the reasoning given be the toolchain people? > > Documentation must be in proper format, some discussion in random bug report > can not be counted as valid documentation. > How does this answer my question? > > so why does this bug block anything? It's a small improvement, but it is an improvement. > > Because it requires editing a lot ebuilds, changing upstream build systems > and explaining upstreams why exactly these changes are required. I fail to see an argument, again. If you don't have the time to fix things, then request help. So I ask you again: * did you not understand the reasoning given by GNU docs, toolchain herd and previous QA lead? * why does this bug report block anything?
As far as i can see, this can be a problem when _user_ has some linking related stuff in his CFLAGS and does not have it in LDFLAGS, because (let's assume) upstreams always take good care of their own required flags. Therefore, it's up to user to set LDFLAGS appropriately, not for Gentoo to enforce CFLAGS on linking command. @qa, please clarify this issue for us. If it's decided to put CFLAGS in linking command, then it must be put into docs.
(In reply to Maxim Koltsov from comment #5) > Therefore, it's up to user to set LDFLAGS appropriately, not for Gentoo to > enforce CFLAGS on linking command. Pretty much nonsensical, since I doubt many people know the details of these things. And why should they care? Most build systems do this by default anyway. So because we are too lazy to enforce consistent behavior, have the user figure out these details on his own? In fact, it has also led to this hack in multilib eclasses (which has caused minor trouble as well): export CC="$(tc-getCC) $(get_abi_CFLAGS)" ...and may break crossdev on various occasions.
this is already documented http://devmanual.gentoo.org/general-concepts/user-environment/index.html it says nowhere that linking command is an exception (especially since it talks about ABI-related flags which MUST be present in linking commands)
<QA hat on> This rule was set a long time ago. CFLAGS MUST be respected both on linking stage and on compile one. Merging CFLAGS variable in LDFLAGS is a bad design idea, which can lead into some weird behaviour in buildsystems like automake. Those flags has different purposes and needed for a completely different things. I do not think that some clarification is needed in our docs(GNU docs says it pretty well, if you are not satisfied with Gentoo documentation) - we must respect CFLAGS as separate variable(no LDFLAGS="${CFLAGS} ${LDFLAGS}" hackery), that's why i close this as WORKSFORME. </QA hat off>
Reopening, as it seems that some of in-tree buildsystems(scons, qmake) did not respect CFLAGS in link command, so i suggest to convert this to tracker bug for this issue, as filing per-ebuild bugs for endpoint programs is a bit useless
Btw., I'm not saying I am against improving the wording of the devmanual on this matter... if anyone feels like doing so, please provide a patch.
No discussion for 2 years, have no clue what should be done here. Feel free to reopen if someone has a specific idea.
