| Summary: | net-news/quiterss does not respect CFLAGS in linking command | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Julian Ospald <hasufell> |
| Component: | Current packages | Assignee: | Qt Bug Alias <qt> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | redblade7 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 508812 | ||
| Bug Blocks: | |||
| Attachments: | quiterss-0.15.3:20140419-180137.log | ||
|
Description
Julian Ospald
2014-04-19 18:07:35 UTC
Is there official Gentoo documentation telling to always include CFLAGS in linking command? (In reply to Nikoli from comment #1) > Is there official Gentoo documentation telling to always include CFLAGS in > linking command? what's with all that "official"? We don't have policies for every possible crap. See bug 446281 for an explanation. I have talked to QA about this as well (the old one), so this is a valid bug. (In reply to Nikoli from comment #1) > Is there official Gentoo documentation telling to always include CFLAGS in > linking command? That's a valid question. Yes it's required, since the CFLAGS include stuff like -Wl,--as-needed which are targeting the linker so they should be present while linking. (In reply to Markos Chandras from comment #3) > since the CFLAGS include stuff like -Wl,--as-needed which Usually, -Wl,--as-needed is not in CFLAGS. > what's with all that "official"? We don't have policies for every possible crap. Your comments are self-contradictory: either this issue is important enough for documenting it and fixing in packages and upstreams or it is not. You reported it for 5 my packages already, so for you it should be significant. > See bug 446281 for an explanation. Respecting CFLAGS is kind of bug that should be fixed upstream too, so i need to provide url to valid explanation for them. Random talk in random bug is not such explanation, it is not usable as documentation or rule: nobody will squeeze through discussions in bugs. Markos, may be open separate bug for clarifying and updating docs? I am still not sure if this 'respect CFLAGS in linking command' is real bug in all cases: a lot packages are doing _only_ linking in linking command; quiterss operates only .o files, it does not have any .c or .cpp files as input for linking command. > Yes it's required, since the CFLAGS include stuff like -Wl,--as-needed which are targeting the linker so they should be present while linking. I only saw --as-needed in LDFLAGS, why would it be in CFLAGS? It seems nothing in Gentoo adds it to CFLAGS and nothing should add. (In reply to Nikoli from comment #5) > > what's with all that "official"? We don't have policies for every possible crap. > > Your comments are self-contradictory Not at all. There are a lot of QA things that are not documented "officially". I don't have to write documentation for every possible thing in order for a report to be a valid bug. > > See bug 446281189 for an explanation. > > Respecting CFLAGS is kind of bug that should be fixed upstream too > Most don't care. I'v been doing this for some time now, so the general approach is... fix this downstream first and then take it to upstream. It's trivial enough. Otherwise you will have ~120 open bugs and 5 upstreams who merge it, 20 say we don't care and the rest doesn't even reply. If you have actual code changes, then it's reasonable to take this to upstream first. > Markos, may be open separate bug for clarifying and updating docs? > I am still not sure if this 'respect CFLAGS in linking command' is real bug > in all cases: a lot packages are doing _only_ linking in linking command; > quiterss operates only .o files, it does not have any .c or .cpp files as > input for linking command. > That's not the point, as outlined in the bug I just linked for you. It's not about "we compile objects during linking stage explicitly", it's about "some flags affect BOTH object compilation AND linking". This is trickier, cause qmake itself generate makefile, that does not respect CFLAGS in linking command. Perhaps some interaction with Qt itself is needed... (In reply to Sergey Popov from comment #7) > This is trickier, cause qmake itself generate makefile, that does not > respect CFLAGS in linking command. Perhaps some interaction with Qt itself > is needed... I suspected that... if qmake is the culprit, then only qmake should be fixed. Please don't add ad-hoc fixes/hacks to random ebuilds until we have determined the root cause. (In reply to Sergey Popov from comment #7) > This is trickier, cause qmake itself generate makefile, that does not > respect CFLAGS in linking command. Perhaps some interaction with Qt itself > is needed... Maybe we should file a bug at qmake upstream? Are they collaborative? Yes, they usually are, although I doubt they'll fix it for qt4... maybe for qt5 and then we can backport. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=264f7fda4fc3324ddab122f4bebee044f34c8bd7 commit 264f7fda4fc3324ddab122f4bebee044f34c8bd7 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-11-16 23:15:06 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-11-16 23:40:12 +0000 profiles: Mask net-news/quiterss for removal See also: https://github.com/QuiteRSS/quiterss/issues/909 Bug: https://bugs.gentoo.org/508160 Bug: https://bugs.gentoo.org/654968 Bug: https://bugs.gentoo.org/687840 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> profiles/package.mask | 6 ++++++ 1 file changed, 6 insertions(+) Package removed. |
