* [FFmpeg-devel] [PATCH] configure: Make MSVC version grabbing more robust
@ 2025-06-13 14:05 Martin Storsjö
2025-06-19 20:21 ` Martin Storsjö
0 siblings, 1 reply; 5+ messages in thread
From: Martin Storsjö @ 2025-06-13 14:05 UTC (permalink / raw)
To: ffmpeg-devel
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".
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [FFmpeg-devel] [PATCH] configure: Make MSVC version grabbing more robust
2025-06-13 14:05 [FFmpeg-devel] [PATCH] configure: Make MSVC version grabbing more robust Martin Storsjö
@ 2025-06-19 20:21 ` Martin Storsjö
2025-06-20 19:25 ` Timo Rothenpieler
0 siblings, 1 reply; 5+ messages in thread
From: Martin Storsjö @ 2025-06-19 20:21 UTC (permalink / raw)
To: ffmpeg-devel
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".
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [FFmpeg-devel] [PATCH] configure: Make MSVC version grabbing more robust
2025-06-19 20:21 ` Martin Storsjö
@ 2025-06-20 19:25 ` Timo Rothenpieler
2025-06-20 20:26 ` Hendrik Leppkes
0 siblings, 1 reply; 5+ messages in thread
From: Timo Rothenpieler @ 2025-06-20 19:25 UTC (permalink / raw)
To: FFmpeg development discussions and patches, Martin Storsjö
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".
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [FFmpeg-devel] [PATCH] configure: Make MSVC version grabbing more robust
2025-06-20 19:25 ` Timo Rothenpieler
@ 2025-06-20 20:26 ` Hendrik Leppkes
2025-06-20 22:03 ` Kacper Michajlow
0 siblings, 1 reply; 5+ messages in thread
From: Hendrik Leppkes @ 2025-06-20 20:26 UTC (permalink / raw)
To: FFmpeg development discussions and patches
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".
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [FFmpeg-devel] [PATCH] configure: Make MSVC version grabbing more robust
2025-06-20 20:26 ` Hendrik Leppkes
@ 2025-06-20 22:03 ` Kacper Michajlow
0 siblings, 0 replies; 5+ messages in thread
From: Kacper Michajlow @ 2025-06-20 22:03 UTC (permalink / raw)
To: FFmpeg development discussions and patches
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".
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-06-20 22:03 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-06-13 14:05 [FFmpeg-devel] [PATCH] configure: Make MSVC version grabbing more robust Martin Storsjö
2025-06-19 20:21 ` Martin Storsjö
2025-06-20 19:25 ` Timo Rothenpieler
2025-06-20 20:26 ` Hendrik Leppkes
2025-06-20 22:03 ` Kacper Michajlow
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git