Re: [FFmpeg-devel] [PATCH] configure: Make MSVC version grabbing more robust

[Kacper Michajlow <kasper93-at-gmail.com@ffmpeg.org>]

On Sat, 21 Jun 2025 at 12:34, Martin Storsjö <martin@martin.st> wrote:
>
> On Sat, 21 Jun 2025, 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)
>
> Sorry about the breakage, and thanks for figuring out what's wrong!
>
> It's odd that this issue didn't appear for me; perhaps it's related to
> running the MSVC tools on Linux wrapped in wine somehow?

I also didn't see an issue. I was running on a server with redirected
output, so it probably also disabled paganination then. Maybe when
there is no console, dunno. I could repro when running interactively
locally.

> > 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.
>
> That sounds like a quite reasonable solution, thanks!
>
> // Martin
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".