> -----Original Message-----
> From: Kacper Michajlow <kaspe...@gmail.com>
> Sent: Tuesday, June 17, 2025 4:06 PM
> To: softworkz . <softwo...@hotmail.com>
> Cc: FFmpeg development discussions and patches <ffmpeg-
> de...@ffmpeg.org>
> Subject: Re: graph.{html,css} embed failure on Windows build
>
> On Tue, 17 Jun 2025 at 15:10, Kacper Michajlow <kaspe...@gmail.com>
> wrote:
> >
> > On Tue, 17 Jun 2025 at 04:07, softworkz . <softwo...@hotmail.com> wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Kacper Michajlow <kaspe...@gmail.com>
> > > > Sent: Sunday, June 15, 2025 12:49 AM
> > > > To: FFmpeg development discussions and patches <ffmpeg-
> > > > de...@ffmpeg.org>
> > > > Cc: softwo...@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
_______________________________________________
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".
