On Sat, 21 Jun 2025 at 12:34, Martin Storsjö <mar...@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....@ffmpeg.org> wrote: > >> > >> On Fri, Jun 20, 2025 at 9:25 PM Timo Rothenpieler <t...@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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
