>Wanted to report a downstream bug at https://bugs.gentoo.org/show_bug.cgi?id=951845
>I don't know enough about build systems to suggest a fix but hopefully
>someone else might.
So, you are supposedly asking a shell to perform word separation using
a
newline and a tab as separators.
The shell is good at this. If you ask your shell to print
${COMMON_FLAGS},
or ${CFLAGS}, I'm sure you'll see the correct result.
The problem you report seems to be triggered by this line:
https://git.skarnet.org/cgi-bin/cgit.cgi/skalibs/tree/configure#n551
which uses $CFLAGS, without quotes: it is supposed to perform word
separation.
The word separation in the skalibs configure script is happening as
intended. You can test it yourself with the following script:
-----
#!/bin/sh -e
CFLAGS="-O2
-pipe"
echo "$CFLAGS"
./configure
-----
(there is a TAB character before -pipe. The echo line is there so you
can check that the CFLAGS variable indeed contains the newline and tab.)
The error message you are getting shows that word separation is not
happening properly: the TAB character is not being interpreted by the
shell, and -flto=auto<TAB>-ftrivial-auto-var-init=zero is parsed as one
word, which cc1 interprets as an invalid argument to -flto.
So my guess is that your ebuild command is doing some nasty quoting
shenanigans before handing the variables to the configure script, and
the evaluation of $CFLAGS results in having one word containing a TAB
rather than what a shell would normally do, i.e. two words.
I suspect ebuild does this *precisely* to accommodate the horrors of
configure scripts created by autotools, and that is the reason why your
ebuild works with autotools. And that it neglected to check that the
result actually looks like something that works with regular shell
variable expansion that non-demented configure scripts would perform.
The skaware configure scripts expect sane variables, ones you construct
naturally with shell commands, not ones that have been tortured to
survive the horrors autotools puts them through. And that is not going
to
change.
I suggest you take a look at ebuild and the way it passes variables
to its configure backends.
--
Laurent
Received on Mon Mar 24 2025 - 19:34:30 CET