Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 508812 - Clarify and document "respecting CFLAGS in linking command"
Summary: Clarify and document "respecting CFLAGS in linking command"
Status: RESOLVED OBSOLETE
Alias: None
Product: [OLD] Docs on www.gentoo.org
Classification: Unclassified
Component: New Documentation (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Quality Assurance Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 508160 508164 506938 508120 508126 508142
  Show dependency tree
 
Reported: 2014-04-26 20:13 UTC by Nikoli
Modified: 2016-06-16 12:15 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikoli 2014-04-26 20:13:34 UTC
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.
Comment 1 Julian Ospald 2014-04-26 20:27:11 UTC
(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?
Comment 2 Julian Ospald 2014-04-26 20:33:36 UTC
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.
Comment 3 Nikoli 2014-04-26 20:38:17 UTC
> > 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.
Comment 4 Julian Ospald 2014-04-26 21:28:40 UTC
(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?
Comment 5 Maxim Koltsov gentoo-dev 2014-04-27 19:36:33 UTC
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.
Comment 6 Julian Ospald 2014-04-27 20:00:30 UTC
(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.
Comment 7 Julian Ospald 2014-04-27 22:51:17 UTC
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)
Comment 8 Sergey Popov gentoo-dev Security 2014-04-28 07:58:50 UTC
<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>
Comment 9 Sergey Popov gentoo-dev Security 2014-04-28 10:41:37 UTC
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
Comment 10 Julian Ospald 2014-04-28 16:58:42 UTC
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.
Comment 11 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-06-16 12:15:27 UTC
No discussion for 2 years, have no clue what should be done here. Feel free to reopen if someone has a specific idea.