Summary: | Decide on the policy around use of unprefixed tools as part of build systems | ||
---|---|---|---|
Product: | Quality Assurance | Reporter: | Kent Fredric (IRC: kent\n) (RETIRED) <kentnl> |
Component: | Policies | Assignee: | Gentoo Quality Assurance Team <qa> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | bertrand, flow, lssndrbarbieri, mgorny, sam, slyfox, zlogene |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=730714 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 243502 | ||
Attachments: | build.log.gz |
Description
Kent Fredric (IRC: kent\n) (RETIRED)
2020-05-29 07:29:59 UTC
Be careful, you have only one leg left as one is gone now. (In reply to Mikle Kolyada from comment #1) > Be careful, you have only one leg left as one is gone now. Can you reply in a way that makes sense to humans? > /var/tmp/portage/app-text/texlive-core-2020-r4/work/texlive-20200406-source/libs/cairo/configure: line 5646: strings: command not found It's 2 bugs: - texlive bundles cairo and tries to use it instead of relying on gentoo's cairo - cairo uses unqualified 'strings' tool from binutils to detect it: https://gitlab.freedesktop.org/cairo/cairo/-/blob/master/build/aclocal.float.m4#L34 Fun fact: autoconf-archive's macro uses grep: to inspect binary. https://github.com/autoconf-archive/autoconf-archive/blob/master/m4/ax_c_float_words_bigendian.m4#L52 (In reply to Sergei Trofimovich from comment #3) > > /var/tmp/portage/app-text/texlive-core-2020-r4/work/texlive-20200406-source/libs/cairo/configure: line 5646: strings: command not found > > It's 2 bugs: > - texlive bundles cairo and tries to use it instead of relying on gentoo's > cairo Actually it does not, there is the --with-system-cairo switch, with that you will not be able to compile tl-core without system cairo being installed. (In reply to Kent Fredric (IRC: kent\n) from comment #2) > (In reply to Mikle Kolyada from comment #1) > > Be careful, you have only one leg left as one is gone now. > > Can you reply in a way that makes sense to humans? this is not a texlive bug at first, at second I would not care if people remove legetimely present symlinks. Actually let's defer the bug to cairo maintainers. Not my area of responsibility to decide how to act on cair itself. *** This bug has been marked as a duplicate of bug 726200 *** (In reply to Mikle Kolyada from comment #5) > (In reply to Kent Fredric (IRC: kent\n) from comment #2) > > (In reply to Mikle Kolyada from comment #1) > > > Be careful, you have only one leg left as one is gone now. > > > > Can you reply in a way that makes sense to humans? > > this is not a texlive bug at first, at second I would not care if people > remove legetimely present symlinks. Then it's time for QA (CCed) to formally decide what bug #243502 is about (and what is legitimate). Going back and forth does not help anyone. The questions to clarify are: 1. Whether gentoo gives user ability to override active C compiler via CC/CXX/AR/LD/READELF/etc. or not. 2. Whether gentoo always expects cpp/cc/gcc/ar/readelf/strings to be used when user does not override CC/CXX and friends. 3. Or default tools must always be prefixed ${CHOST}-cpp/${CHOST}-gcc. 4. Or default can be a mix and mix is guaranteed to work (with all the implications of silent breakages when cross-compiling). Current gentoo state is such that autoconf & friends never use unprefixed cpp/cc/gcc tools as gentoo always passes --build= and --host parameters as part of econf. Unless someone makes a mistake or hardcodes unprefixed tool use instead of using AC_CHECK_TOOL. My opinion below. > 1. Whether gentoo gives user ability to override active C compiler via > CC/CXX/AR/LD/READELF/etc. or not. Yes, we want that to work. Not sure about LD as it's kinda special (I recall some build systems being broken when LD was specified because it overrode using CC/CXX to link). > 2. Whether gentoo always expects cpp/cc/gcc/ar/readelf/strings to be used > when user does not override CC/CXX and friends. No for the first three. For the remaining, no strong opinion. > 3. Or default tools must always be prefixed ${CHOST}-cpp/${CHOST}-gcc. > 4. Or default can be a mix and mix is guaranteed to work (with all the > implications of silent breakages when cross-compiling). No, the mix can break stuff. Long story short, we should use prefix tools as part of *toolchain* but we should permit unprefixed in other contexts. My repeated example is using ar to unpack ar archives as part of .deb processing. The entire situation in the current reality is a wild goose chase. We should respect AR/CC/GCC/CPP, until there is a very special case where a maintainer is sure direct calls will not break the package badly. I have no strong opinion about pther toolchain like STRINGS or NM. We should not turn this into a silly chase like "respect everything || die" I do agree that [-native-symlynks] is useful for debugging, but please nit turning it into a mandatory item. (In reply to Mikle Kolyada from comment #10) > The entire situation in the current reality is a wild goose chase. In reality: 90% of packages already work *just fine* with nuked symlinks. And of the 10% that fail, at least 90% of those are trivial fixes, which do the right thing. So .... maybe investigate the change before writing it off as a red herring. (In reply to Mikle Kolyada from comment #10) > We should respect AR/CC/GCC/CPP until there is a very special case where a maintainer is sure direct calls will not break the package badly. I don't agree with the premise. I think it's worth stating real goal of 'tc-directly'. My view of 'tc-directly' is: AR/CC/CPP overrides are provided not just to fix/workaround build failures. But allow user to swap the tool's implementation (for whatever reason: testing the implementation, working things around, going wild). The point of available override is (if you like) to allow user to break package badly with a single variable change (and not discover the breakage after 'gcc-config' run, or manual symlink twiddling). Especially if substitution is trivial to achieve. Thus it's not ok to call "/lib/cpp" or "cpp" directly just because it happens to work. But it might be ok to leave if it's not practical to override. For packages like 'wine' where it's really hard to achieve 'as' tool substitution without upstream patching. Perhaps gathering more specific cases of "too hard/to brittle" would help here. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=d0bced7586bcab1a00a8db11baae895bd4f0a646 commit d0bced7586bcab1a00a8db11baae895bd4f0a646 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-08-01 02:28:43 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-08-14 01:42:58 +0000 ebuild-writing/functions/src_compile/building: don't call CC directly Bug: https://bugs.gentoo.org/243502 Bug: https://bugs.gentoo.org/726034 Signed-off-by: Sam James <sam@gentoo.org> Closes: https://github.com/gentoo/devmanual/pull/243 Signed-off-by: Sam James <sam@gentoo.org> ebuild-writing/functions/src_compile/building/text.xml | 9 +++++++++ 1 file changed, 9 insertions(+) |