On Tue, 17 Jun 2025 at 18:07, softworkz . <softwo...@hotmail.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Kacper Michajlow <kaspe...@gmail.com>
> > Sent: Tuesday, June 17, 2025 6:00 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 17:29, softworkz . <softwo...@hotmail.com> wrote:
> > >
> > > > -----Original Message-----
> > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
> > > > softworkz .
> > > > Sent: Tuesday, June 17, 2025 4:13 PM
> > > > To: Kacper Michajlow <kaspe...@gmail.com>
> > > > Cc: FFmpeg development discussions and patches <ffmpeg-
> > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] graph.{html,css} embed failure on
> > > > Windows build
> > > >
> > > >
> > > > > -----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
> > >
> > > 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?
I think this config is criminally underused. Everyone thinks MSVC
(cl.exe) only when talking about Visual Studio. But actually they are
shipping LLVM toolchain which is a great way to build software with
Windows SDK (without mingw) that is not MSVC (cl.exe) compatible. Of
course mingw and llvm-mingw have existed for a long time and are goto
solutions for such cases, but I find it nice to run software with
standard SDK.
To answer your questions, depends how much resources you want to throw
at that. I wouldn't say this configuration is critical. Though at
least one Clang based Windows build would be good to have, whether
llvm-mingw or clang-msvc. Note I don't mean clang-cl because this
thing is supposed to be closely compatible with MSVC itself, so in
theory if cl.exe is working clang-cl.exe should do too.
- 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-requ...@ffmpeg.org with subject "unsubscribe".
