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

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

[Martin Storsjö]

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(-)

diff --git a/configure b/configure
index 534b443f7d..98a3b3814f 100755
--- a/configure
+++ b/configure
@@ -5127,7 +5127,10 @@ probe_cc(){
     elif $_cc -nologo- 2>&1 | grep -q Microsoft || { $_cc -v 2>&1 | grep -q clang && $_cc -? > /dev/null 2>&1; }; then
         _type=msvc
         if $_cc -nologo- 2>&1 | grep -q Microsoft; then
-            _ident=$($_cc 2>&1 | head -n1 | tr -d '\r')
+            # The version number is printed on the first line on stderr, stdout
+            # gets the usage instructions. Only include stderr, to avoid
+            # potential ordering race conditions.
+            _ident=$($_cc 2>&1 >/dev/null | head -n1 | tr -d '\r')
         else
             _ident=$($_cc --version 2>/dev/null | head -n1 | tr -d '\r')
         fi
-- 
2.43.0

_______________________________________________
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".

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

[Martin Storsjö]

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.

// 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".

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

[Timo Rothenpieler]

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.
_______________________________________________
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".

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

[Hendrik Leppkes]

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)

- Hendrik
_______________________________________________
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".

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

[Kacper Michajlow]

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.

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

- Kacper
_______________________________________________
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".

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

[Alexander Strasser via ffmpeg-devel]

[-- Attachment #1: Type: message/rfc822, Size: 10727 bytes --]

[-- Attachment #1.1.1: Type: text/plain, Size: 3053 bytes --]

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

[-- Attachment #1.1.2: 0001-configure-Fix-a-regression-when-probing-link.exe.patch --]
[-- Type: text/plain, Size: 1405 bytes --]

From f97df3657ab73573659d7738ac55d688c5744bf9 Mon Sep 17 00:00:00 2001
From: Alexander Strasser <eclipse7@gmx.net>
Date: Sat, 21 Jun 2025 11:13:22 +0200
Subject: [PATCH] configure: Fix a regression when probing link.exe

The version ident is printed on stdout for link.exe and redirecting
stdout to /dev/null will cause the output of link.exe to be paged.
---
 configure | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index 708ecd9025..ce027d3845 100755
--- a/configure
+++ b/configure
@@ -5130,10 +5130,9 @@ probe_cc(){
     elif $_cc -nologo- 2>&1 | grep -q ^Microsoft || { $_cc -v 2>&1 | grep -q clang && $_cc -? > /dev/null 2>&1; }; then
         _type=msvc
         if $_cc -nologo- 2>&1 | grep -q ^Microsoft; then
-            # The version number is printed on the first line on stderr, stdout
-            # gets the usage instructions. Only include stderr, to avoid
-            # potential ordering race conditions.
-            _ident=$($_cc 2>&1 >/dev/null | head -n1 | tr -d '\r')
+            # Depending on the tool (cl.exe or link.exe), the version number
+            # is printed on the first line of stderr or stdout
+            _ident=$($_cc 2>&1 | grep ^Microsoft | head -n1 | tr -d '\r')
         else
             _ident=$($_cc --version 2>/dev/null | head -n1 | tr -d '\r')
         fi
-- 
2.49.0


[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Martin Storsjö]

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?

> 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".

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

[Martin Storsjö]

> On 21. Jun 2025, at 12.20, Alexander Strasser via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> 
> 
> 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:
>>>> 
>>>> 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
> <0001-configure-Fix-a-regression-when-probing-link.exe.patch>

Thanks, this patch looks good to me, feel free to push! (And I can push it later today if nobody else does it before that.)

If you want to, one can also extend the commit message further to say more explicitly, that 45a30e03613a3c63d74a40f7ac86ce28dce14ff8 caused configure to hang in some configurations, which this fixes.

// 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".

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

[Kacper Michajlow]

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".

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

[Martin Storsjö]

On Sat, 21 Jun 2025, Kacper Michajlow wrote:

> 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.

Interesting, thanks!

Can you confirm that Alexander's patch fixes the issue?

// 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".

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

[Alexander Strasser via ffmpeg-devel]

[-- Attachment #1: Type: message/rfc822, Size: 10747 bytes --]

[-- Attachment #1.1.1: Type: text/plain, Size: 2711 bytes --]

Hi Martin!

On 2025-06-21 13:37 +0300, Martin Storsjö wrote:
> > On 21. Jun 2025, at 12.20, Alexander Strasser via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> > 
> > 
> > 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:
> >>>> 
> >>>> 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
> > <0001-configure-Fix-a-regression-when-probing-link.exe.patch>
> 
> Thanks, this patch looks good to me, feel free to push! (And I can push it later today if nobody else does it before that.)
> 
> If you want to, one can also extend the commit message further to say more explicitly, that 45a30e03613a3c63d74a40f7ac86ce28dce14ff8 caused configure to hang in some configurations, which this fixes.

I have attached an updated version. Hope you like the commit message
better.

I can push it tomorrow or you can do earlier.


Thanks,
  Alexander

[-- Attachment #1.1.2: 0001-v2-configure-Fix-a-regression-when-probing-link.exe.patch --]
[-- Type: text/plain, Size: 1647 bytes --]

From d71f2bd07a9a723158fb1ec59ec7398fe7aee577 Mon Sep 17 00:00:00 2001
From: Alexander Strasser <eclipse7@gmx.net>
Date: Sat, 21 Jun 2025 11:13:22 +0200
Subject: [PATCH] configure: Fix a regression when probing link.exe

The version ident is printed on stdout for link.exe and redirecting
stdout to /dev/null will cause the output of link.exe to be paged.

This caused configure to hang for some configurations and by
extension some FATE clients. You might want to check if you run
affected configurations automated in FATE clients or similar setups.

Fixes: 45a30e03613a3c63d74a40f7ac86ce28dce14ff8
---
 configure | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index 708ecd9025..ce027d3845 100755
--- a/configure
+++ b/configure
@@ -5130,10 +5130,9 @@ probe_cc(){
     elif $_cc -nologo- 2>&1 | grep -q ^Microsoft || { $_cc -v 2>&1 | grep -q clang && $_cc -? > /dev/null 2>&1; }; then
         _type=msvc
         if $_cc -nologo- 2>&1 | grep -q ^Microsoft; then
-            # The version number is printed on the first line on stderr, stdout
-            # gets the usage instructions. Only include stderr, to avoid
-            # potential ordering race conditions.
-            _ident=$($_cc 2>&1 >/dev/null | head -n1 | tr -d '\r')
+            # Depending on the tool (cl.exe or link.exe), the version number
+            # is printed on the first line of stderr or stdout
+            _ident=$($_cc 2>&1 | grep ^Microsoft | head -n1 | tr -d '\r')
         else
             _ident=$($_cc --version 2>/dev/null | head -n1 | tr -d '\r')
         fi
-- 


[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Kacper Michajlow]

On Sat, 21 Jun 2025 at 19:18, Alexander Strasser via ffmpeg-devel
<ffmpeg-devel@ffmpeg.org> wrote:
>
>
>
>
> ---------- Forwarded message ----------
> From: Alexander Strasser <eclipse7@gmx.net>
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Cc:
> Bcc:
> Date: Sat, 21 Jun 2025 19:18:03 +0200
> Subject: Re: [FFmpeg-devel] [PATCH] configure: Make MSVC version grabbing more robust
> Hi Martin!
>
> On 2025-06-21 13:37 +0300, Martin Storsjö wrote:
> > > On 21. Jun 2025, at 12.20, Alexander Strasser via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> > >
> > >
> > > 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:
> > >>>>
> > >>>> 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
> > > <0001-configure-Fix-a-regression-when-probing-link.exe.patch>
> >
> > Thanks, this patch looks good to me, feel free to push! (And I can push it later today if nobody else does it before that.)
> >
> > If you want to, one can also extend the commit message further to say more explicitly, that 45a30e03613a3c63d74a40f7ac86ce28dce14ff8 caused configure to hang in some configurations, which this fixes.
>
> I have attached an updated version. Hope you like the commit message
> better.
>
> I can push it tomorrow or you can do earlier.

LGTM. I tested locally for link.exe and cl.exe. As for server/fate
testing, I think we can push and monitor if runners are unblocked.
People have things automated, so it probably takes "effort" to just do
manual patch testing out-of-tree.

- Kacper
_______________________________________________
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".