From: "Martin Storsjö" <martin@martin.st>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] configure: Make MSVC version grabbing more robust
Date: Sat, 21 Jun 2025 19:04:37 +0300 (EEST)
Message-ID: <dbf4cd7e-4ce0-dd2-b732-32294d7ee11@martin.st> (raw)
In-Reply-To: <CABPLASS_85wstJ3cyuZ9g+YrbB2WY4WMgJVmF1_oqsdd0+=KGg@mail.gmail.com>
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".
prev parent reply other threads:[~2025-06-21 16:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-13 14:05 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
2025-06-21 9:20 ` Alexander Strasser via ffmpeg-devel
2025-06-21 10:37 ` Martin Storsjö
2025-06-21 17:18 ` Alexander Strasser via ffmpeg-devel
2025-06-21 18:45 ` Kacper Michajlow
2025-06-21 19:49 ` Martin Storsjö
2025-06-21 10:34 ` Martin Storsjö
2025-06-21 11:55 ` Kacper Michajlow
2025-06-21 16:04 ` Martin Storsjö [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dbf4cd7e-4ce0-dd2-b732-32294d7ee11@martin.st \
--to=martin@martin.st \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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