Re: configure fails with gcc 4.6.0 LTO

[Mike Frysinger]

On Mon, Mar 21, 2011 at 8:32 AM, Greg Wooledge wrote:
> On Sat, Mar 19, 2011 at 09:52:05PM +0000, Zeev Tarantov wrote:
>> configure:3122: checking for C compiler default output file name
>> configure:3144: x86_64-pc-linux-gnu-gcc -g -O2 -flto
>> -DDEFAULT_PATH_VALUE='"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"'
>> -DSTANDARD_UTILS_PATH='"/bin:/usr/bin:/sbin:/usr/sbin"'
>> -DSYS_BASHRC='"/etc/bash/bashrc"'
>> -DSYS_BASH_LOGOUT='"/etc/bash/bash_logout"'
>> -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -Wl,-flto
>> conftest.c  >&5
>> x86_64-pc-linux-gnu-gcc: error: \: No such file or directory
>> x86_64-pc-linux-gnu-gcc: error: \: No such file or directory
>> x86_64-pc-linux-gnu-gcc: error: \: No such file or directory
>> x86_64-pc-linux-gnu-gcc: error: \: No such file or directory
>> lto-wrapper: 
>> /usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0-pre9999/x86_64-pc-linux-gnu-gcc
>> returned 1 exit status
>
> I'm not sure how much of the distortion we're seeing here is being
> caused by a mail user agent, versus how much is caused by the experimental
> gcc he's using, etc.
>
> My guess, without knowing anything about this version of gcc, is that
> the command that ./configure is supposed to execute is really something
> like:
>
> x86_64-pc-linux-gnu-gcc -g -O2 -flto \
>  
> -DDEFAULT_PATH_VALUE='"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"'
>  \
>  -DSTANDARD_UTILS_PATH='"/bin:/usr/bin:/sbin:/usr/sbin"' \
>
> and so on, where the backslashes are supposed to be at the ends of the
> lines, to indicate continuation.  And somewhere along the way, they're
> being doubled so that they're becoming literal words.
>
> imadev:/tmp$ /net/appl/gcc-3.3/bin/gcc -g -O2 -DFOO=BAR \\ -DQWERTY=UIOP \\ 
> hello.c
> gcc: \: No such file or directory
> gcc: \: No such file or directory
>
> Kinda like that.
>
> Maybe it's gcc 4.6-prewhatever that's doing it.  Maybe he's actually using
> some sort of "build system wrapper" that's broken.  I don't know.  I just
> recognize the symptom, not the cause.

the Gentoo ebuild double quotes the flags in env CPPFLAGS so that gcc
sets the strings correctly when compiling.

the failure only happens when LDFLAGS contains -flto which says to me
that gcc doesnt parse arguments the same as when executing other
helpers.

LDFLAGS=-flto CPPFLAGS=-DD=\'\"\"\' ./configure
<fail>

but still not a bash issue
-mike