On 2025-06-21 00:03 +0200, Kacper Michajlow wrote:
> On Fri, 20 Jun 2025 at 22:26, Hendrik Leppkes
> <h.leppkes-at-gmail.com@ffmpeg.org> wrote:
> >
> > On Fri, Jun 20, 2025 at 9:25 PM Timo Rothenpieler <timo@rothenpieler.org> wrote:
> > >
> > > On 19.06.2025 22:21, Martin Storsjö wrote:
> > > > On Fri, 13 Jun 2025, Martin Storsjö wrote:
> > > >
> > > >> When running plain "cl", to get the MSVC version, it prints the
> > > >> version header on stderr, while the usage instructions are printed
> > > >> on stdout. Usually, the version on stderr gets flushed first,
> > > >> so "head -n1" gets the line it expects, but some times (in particular
> > > >> when running MSVC wrapped in wine), it can get the usage line
> > > >> first.
> > > >>
> > > >> Redirect stdout to /dev/null, so we only grab the version among
> > > >> the lines printed to stderr. This should make the version number
> > > >> grabbing more robust.
> > > >>
> > > >> At least all relevant versions of MSVC seem to print this specifically
> > > >> to stderr, not stdout (so we don't risk to miss it); checked down
> > > >> to MSVC 2010.
> > > >> ---
> > > >> This should avoid the occasionally misdetected version number lines
> > > >> as seen at https://fate.ffmpeg.org/history.cgi?slot=x86_64-msvc2022-wine.
> > > >> ---
> > > >> configure | 5 ++++-
> > > >> 1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > Will push.
> > >
> > > Likely this patch broke multiple fate runners in a silent way.
> > > On mine, configure simply never returns, and just sits there
> > > indefinitely, with no CPU usage or any activity whatsoever.
> > >
> > > nevcairiel confirmed seeing the same behaviour on IRC.
> > >
> > > The msys+clang builds from within the same environment work fine.
> > >
> > >
> > > Didn't verify completely if it's caused by this patch, but nothing else
> > > happened with configure since the last successful run.
> >
> > I did some digging, and it happens when probe_cc probes link.exe
> >
> > link.exe has an interactive help output (its paginated) - previously
> > piping stdout disabled the pagination automatically - but redirecting
> > it to devnull does not, and it gets stuck waiting for input.
> > Additionally, link.exe outputs the ident on stdout, so there is no
> > result on stderr (not super bad, as LD_IDENT is never used - yet)
> 
> Instead of redirecting to devnull, we could use the same condition as
> in if. We already look for specific ident line, so no need to head.
> _ident=$($_cc -nologo- 2>&1 | grep ^Microsoft | tr -d '\r')
> should work, no? I would be happy to see a better solution, though.

I think making sure to only use the first line that starts with
Microsoft is more robust; there could be (in the future) more lines
that start with Microsoft.

> btw. running cl.exe 3 times to just get its name is interesting :)

Yes, so that as well. Could be optimized, but is probably not so
relevant in total.

I propose the attached patch.


  Alexander