Re: [FFmpeg-devel] graph.{html,css} embed failure on Windows build

["softworkz ." <softworkz-at-hotmail.com@ffmpeg.org>]

> -----Original Message-----
> From: Kacper Michajlow <kasper93@gmail.com>
> Sent: Tuesday, June 17, 2025 6:00 PM
> To: softworkz . <softworkz@hotmail.com>
> Cc: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: graph.{html,css} embed failure on Windows build
> 
> On Tue, 17 Jun 2025 at 17:29, softworkz . <softworkz@hotmail.com> wrote:
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > softworkz .
> > > Sent: Tuesday, June 17, 2025 4:13 PM
> > > To: Kacper Michajlow <kasper93@gmail.com>
> > > Cc: FFmpeg development discussions and patches <ffmpeg-
> > > devel@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] graph.{html,css} embed failure on
> > > Windows build
> > >
> > >
> > > > -----Original Message-----
> > > > From: Kacper Michajlow <kasper93@gmail.com>
> > > > Sent: Tuesday, June 17, 2025 4:06 PM
> > > > To: softworkz . <softworkz@hotmail.com>
> > > > Cc: FFmpeg development discussions and patches <ffmpeg-
> > > > devel@ffmpeg.org>
> > > > Subject: Re: graph.{html,css} embed failure on Windows build
> > > >
> > > > On Tue, 17 Jun 2025 at 15:10, Kacper Michajlow
> > > > <kasper93@gmail.com>
> > > > wrote:
> > > > >
> > > > > On Tue, 17 Jun 2025 at 04:07, softworkz .
> > > > > <softworkz@hotmail.com>
> > > wrote:
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Kacper Michajlow <kasper93@gmail.com>
> > > > > > > Sent: Sunday, June 15, 2025 12:49 AM
> > > > > > > To: FFmpeg development discussions and patches <ffmpeg-
> > > > > > > devel@ffmpeg.org>
> > > > > > > Cc: softworkz@hotmail.com
> > > > > > > Subject: graph.{html,css} embed failure on Windows build
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > Since the recent addition of resman.c and embedding of
> > > > > > > graph.{html,css} some of the Windows builds fail. There
> > > > > > > seems to be a regression in path joining, caused by \ / mismatch.
> > > > > > >
> > > > > > > Generally those issues were never a problem and I would
> > > > > > > prefer to keep it this way. This configuration has always
> > > > > > > been flaky and
> > > > undertested.
> > > > > > > I could set-up a pipeline to report to the fate server if
> > > > > > > that's something that would help stabilize it.
> > > > > > >
> > > > > > > Example of failure:
> > > > > > > ```
> > > > > > > BIN2C fftoolsresourcesgraph.html.c BIN2C
> > > > > > > fftools/resources/graph.html.c SED
> > > > > > > fftoolsresourcesgraph.css.min
> > > > > > > sed: can't read
> > > > > > > /c/a/FFmpeg/FFmpeg/fftoolsresources/graph.css: No such file
> > > > > > > or directory SED fftools/resources/graph.css.min
> > > > > > > make: *** No rule to make target
> > > > > > > 'fftools\resources\graph.html.c', needed by
> 'fftools/resources/graph.html.o'. Stop.
> > > > > > > make: *** Waiting for unfinished jobs....
> > > > > > > HOSTCC tests/videogen.o
> > > > > > > rm fftools\resources\graph.css.min
> > > > > > > fftools/resources/graph.html.c ```
> > > > > > >
> > > > > > > Note that BIN2C is called twice, once with the correct path
> > > > > > > and with the wrong one.
> > > > > > >
> > > > > > > Removing resman.c fixes the build. This has to be done
> > > > > > > forcefully in the code, because there is no configure option
> > > > > > > to disable this
> > > html/css
> > > > embedding.
> > > > > > >
> > > > > > > You can see the details and whole failing build logs here:
> > > > > > > code: https://github.com/kasper93/FFmpeg/tree/gha
> > > > > > > build:
> > > > > > >
> > > >
> https://github.com/kasper93/FFmpeg/actions/runs/15653223193/job/44
> > > > > > > 100
> > > > > > > 735119
> > > > > > > command: $ ../configure --enable-gpl --enable-version3
> > > > > > > --enable-nonfree -- samples=../samples
> > > > > > > --enable-memory-poisoning
> > > > > > > --arch=amd64 --enable-w32threads --as=clang --ar=llvm-ar
> > > > > > > --cxx=clang++ -- ld=lld-link --windres=llvm-windres
> > > > > > > --strip=llvm-strip --cc=clang --nm=llvm-nm
> > > > > > > --extra-ldflags='msvcrt.lib
> > > > oldnames.lib'
> > > > > > > --host_extralibs='' --toolchain=msvc && make -j`nproc` &&
> > > > > > > make -j`nproc` run-checkasm && make -j`nproc` fate-rsync &&
> > > > > > > make -j`nproc` fate
> > > > > > >
> > > > > > > Here is exactly the same pipeline with removed
> > > > > > > graph.{html,css}
> > > > > > > https://github.com/kasper93/FFmpeg/tree/gha2
> > > > > > > https://github.com/kasper93/FFmpeg/actions/runs/15656127992
> > > > > > > Builds just fine.
> > > > > > > Ignore win32 (windows-11-arm, arm64, --toolchain=msvc)
> > > > > > > failure, as this is affected by unrelated regression in
> > > > > > > dxvenc.c on arm64 target, but the build itself is passing just fine.
> > > > > > >
> > > > > > > Any ideas how we can restore the ability to build ffmpeg on
> Windows?
> > > > > >
> > > > > > Hi Kasper,
> > > > > >
> > > > > > I was able to reproduce the issue by adding a new CI build
> > > > > > (for PRs to ffstaging/ffmpeg (on GitHub, not yet for Patchwork).
> > > > > >
> > > > > > It appears to be all about dir separators when building under
> > > > > > MSYS2 with Clang. Clang insists on using backslashes (unlike
> > > > > > GCC and MSVC) and that screws the Gnu make logic (pattern
> > > > > > rules, dependency and up-to-date checks).
> > > > >
> > > > > Why is Clang involved in .css conversion rules? It seems to fail
> > > > > at the `%.css.min: %.css` rule already, which shouldn't involve
> > > > > any C toolchain related bits. Is this propagated from the .o
> > > > > file? In which case why does the .o have "wrong" path separators?
> > > > >
> > > > > Isn't there an issue in vpath? Maybe we can make it somehow
> > > > > proper separators. Few days I briefly looked at this, but it
> > > > > wasn't obvious what would be the correct solution here. Changing
> > > > > vpath to extract only files in fftools/resources was improving
> > > > > things, but still not fully.
> > > > >
> > > > > Also vpath in fftools/resources/Makefile is setting search path
> > > > > in the whole SRC_PATH, while imho it should be restricted to the
> > > > > fftools/resources directory only.
> > > > >
> > > > > - Kacper
> > > >
> > > > Ok, Martin explained to me on IRC that Windows Clang is generating
> > > > dependency files with backward slashes, which is then choking
> > > > because
> > > Make
> > > > ingest that, which when not escaped \\ makes paths all go wrong.
> > > >
> > > > There is no issue with llvm-mingw or alike, because Clang can be
> > > > configured during compile time to output forward slashes in dep files.
> > > >
> > > > So, probably a solution would be to postproc .d files. But I
> > > > didn't look at the issue closely, as you can see :) Or make Make
> > > > work with backward slashes where needed, but this may be tricky to
> cover all internal matching.
> > > >
> > > > Dunno, just wanted to correct my previous message.
> > >
> > > Hi Kasper,
> > >
> > > thanks a lot for the update.
> > > I had found this (path in dependency files) as a possible issue from
> > > research but disregarded it because I had already stopped creation
> > > of .d files for resources.
> > >
> > > BUT - now I realize: That change hasn't even been merged into master
> yet.
> > >
> > > Will run the CI with those changes included and report back.
> > >
> > > Thank you,
> > > sw
> >
> > Hi Kasper,
> >
> > my already submitted patchset indeed fixes the MSVC-CLang build
> > configuration which you had reported as failing:
> >
> > PR:
> > https://github.com/ffstaging/FFmpeg/pull/80
> >
> > Build log:
> > https://dev.azure.com/githubsync/ffmpeg/_build/results?buildId=95960&v
> > iew=logs&j=275f1d19-1bd8-5591-b06b-07d489ea915a
> >
> > I will wait for the remaining CI builds to succeed and submit the
> > rebased patchset to the ML then.
> >
> > Please let me know whether it fixes the build on your side as well.
> 
> Yes, this fixes the build issue. Thanks.

Thanks for confirming. Patch update sent.

> Note, I created a pipeline to upload this failing configuration to the fate server.
> So we have coverage of this config now. Things tend to break if something is
> not tested.	

Yup - but that's testing only after merge to master. 
I'm thinking about adding an additional check build for Patchwork.
Do you think your configuration is common enough to do this? Or is there a more
typical configure setup for this kind of build (Win-CLang) that would make more
sense for the project?

Thanks again and sorry for the disruption,
sw


  

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