Don't parse gcc -v / gfortran -v blindly

[yuyichao]

f_check and c_check seems to parse the output of gcc -v / gfortran -v without any attempt to distinguish different part of the output. This seems to be extremely fragile and can break whenever new outputs were added that just happens to look like a linker flag even if it might be flags for something else or completely unrelated strings.

In particular, this cause a compile error under GCC 10 if running under a parallel make with job server and if the -l flag is in the MAKEFLAGS. Since gcc is started by perl and doesn't have the jobserver fd, GCC 10 correctly disabled job server support (after gcc-mirror/gcc@e006ead52305) which causes the new MAKEFLAGS to be printed to the output when -v is on. The make flag is then being blindly interpreted as a linker flag and cause an error in the link test!

[martin-frbg]

"without any attempt" seems a bit harsh, it just cannot distinguish parts it does not yet know. I did not notice this with earlier snapshots of gcc10 - could you provide a log that shows the problem ?
(Edited to add "earlier snapshots" meaning those from earlier this year, so certainly after the jobserver-related change you mentioned)

[yuyichao]

"without any attempt" seems a bit harsh, it just cannot distinguish parts it does not yet know.

What I meant by

distinguish different part of the output

is that the output of -v is in some way stateful. It is not simply an unstructured uniform dump of random information, but contains clearly different parts like version numbers, configure flags, paths, envs, subcommands, etc. each with completely different context dependent parsing rules and most of these can even be translated. However, the two scripts parse the output by cutting it into small pieces which discards all context information and that's what I mean by "without any attempt". Note that I don't mean that making an attempt is the right solution. The -v output is for debugging. GCC can really throw whatever useful for debugging there and break these scripts in whichever ways they want. What I meant by "don't do it blindly" is really "don't do it".

I did not notice this with earlier snapshots of gcc10

You need

running under a parallel make with job server and if the -l flag is in the MAKEFLAGS

or in another word, run MAKEFLAGS="-j2 -l2" make ....

To see this happen more easily,

% echo | MAKEFLAGS='--jobserver-auth=4,5 -j2 -l2' gcc -x c -v - -o /dev/null -c 2>&1 | grep 'l2'
MAKEFLAGS= -j2 -l2

The easiest way to work around it for now is to just unset MAKEFLAGS (and maybe set LANG related envs as well for good measure). However, this will certainly break again in the future.

[brada4]

MAKEFLAGS as per posix is intended to change behaviour of make command. Just dont set them firsthand since the changed behaviour is unacceptable?

[martin-frbg]

Suspect this is in the context of a bigger build, have not tried yet but perhaps we can unset/unexport MAKEFLAGS from the toplevel Makefile to limit the "damage".

[brada4]

But why - if a person intends to posixly change build behaviour they now cannot?

[yuyichao]

The workaround I was talking about was to unset/set the env in the perl script. Messing with MAKEFLAGS in Makefile is basically an unaccepable solution.

[yuyichao]

Just dont set them firsthand since the changed behaviour is unacceptable?

I'm not sure what you are trying to say here. FWIW, I never explicitly set the MAKEFLAGS anywhere, they are set by the build server to support parallel build. Unless you want to say that parallel build is not supported "don't set them firsthand" is not a solution.

As a side note, passing the MAKEFLAGS as command line argument has exactly the same effect. MAKEFLAGS is how make pass arguments to nested makes and running make -j8 -l8 will cause -j8 -l8 to appear in the MAKEFLAGS even if the env was not set by the user. This is also why one should not mess with MAKEFLAGS in Makefile.

[martin-frbg]

Easiest (if ugliest) fix seems to be to ignore any all-numeric "library names" when determining the linker options.