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

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

[Kacper Michajlow]

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/44100735119
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?

Thanks,
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-request@ffmpeg.org with subject "unsubscribe".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 884 bytes --]

Hi Kacper

On Sun, Jun 15, 2025 at 12:48:50AM +0200, Kacper Michajlow wrote:
> 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.

my reply to "more testing" is basically always "yes please"

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

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

[softworkz .]

________________________________________
From: Kacper Michajlow <kasper93@gmail.com>
Sent: Sunday, June 15, 2025 12:48 AM
To: FFmpeg development discussions and patches
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/44100735119
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?

Thanks,
Kacper


Hello Kasper,

this is a quite specific configure setup. There are two Patchwork CI
builds for Windows (one MSVC and one GCC, both on MSYS2) which
are working fine.

I'm on vacation, so my abilities are somewhat limited, please give me 
a week, then i'll look at your way of configuration and why it fails.

Best regards
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".

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

[softworkz .]

________________________________________
From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> on behalf of softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Sent: Sunday, June 15, 2025 3:20 AM
To: Kacper Michajlow; FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] graph.{html,css} embed failure on Windows build




________________________________________
From: Kacper Michajlow <kasper93@gmail.com>
Sent: Sunday, June 15, 2025 12:48 AM
To: FFmpeg development discussions and patches
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/44100735119
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?

Thanks,
Kacper


Hello Kasper,

this is a quite specific configure setup. There are two Patchwork CI
builds for Windows (one MSVC and one GCC, both on MSYS2) which
are working fine.

I'm on vacation, so my abilities are somewhat limited, please give me
a week, then i'll look at your way of configuration and why it fails.

Best regards
sw
_______________________________________________


Some additional notes:

1. Sorry for the missing quotes in this reply

2. @kasper: Does the compilation of CUDA filters work with your setup?
  Because the resources are using the exact same mechanism as we have
  for compiling *.cu files to *.ptx files and embedding these into FFmpeg
  (just another kind of resources).
  These procedures exist in FFmpeg for years already and I actually
  re-used this precedent exactly for the reason that nobody can complain
  that it would introduce something new that could be show-stopping 
  for anybody.

3. If someone finds this conversation who is using the Shift Media Project's 
  Visual Studio project generator, please note that I have submitted PRs
  to fix this and some other recent FFmpeg changes which broke it. I also 
  submitted a fix for CUDA filters - these had never worked before - as 
  mentioned, both are more or less the same story.
  https://github.com/ShiftMediaProject/FFVS-Project-Generator

Best regards,
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".

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

[softworkz .]

> -----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/44100
> 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).

If you need a quick unblock regarding compilation, you can try the commit
from this PR: https://github.com/ffstaging/FFmpeg/pull/100

It builds successfully, but FATE tests are failing (endless loop):
https://dev.azure.com/githubsync/ffmpeg/_build/results?buildId=95750&view=logs&j=275f1d19-1bd8-5591-b06b-07d489ea915a

Being off-site at the moment, I'm somewhat limited, but maybe It's helpful
for the moment, at least.

Best regards,
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".

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

[Kacper Michajlow]

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

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

[Kacper Michajlow]

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/44100
> > > 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.

- Kacper

- 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-request@ffmpeg.org with subject "unsubscribe".

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

[softworkz .]

> -----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




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

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

[softworkz .]

> -----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&view=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.

Thanks,
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".

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

[Kacper Michajlow]

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&view=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.

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.

- 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-request@ffmpeg.org with subject "unsubscribe".

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

[softworkz .]

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

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

[Kacper Michajlow]

On Tue, 17 Jun 2025 at 18:07, softworkz . <softworkz@hotmail.com> wrote:
>
>
>
> > -----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?

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-request@ffmpeg.org with subject "unsubscribe".

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

[softworkz .]

> -----Original Message-----
> From: Kacper Michajlow <kasper93@gmail.com>
> Sent: Tuesday, June 17, 2025 6:36 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

[..]

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

It still needs MSYS2 for the Gnu build system, but yea, I get the point of 
using the platform SDK directly.
How's the resulting binaries' performance? I'm using the SMP project 
generator which allows you to actually work and debug in VS like with
any other MSVC project/solution, but for production compiles, that's 
not an option as it's way slower than the GCC/MSYS2/mingw path..


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

Now that andriy/make_x86 is active again, I can disable softworkz/make_linux_x64,
which is almost the same. The mac run is the fastest and of no concern, Linux-shared
and Linux-out-of-tree don't run FATE. The heavy-weights are Win-MSVC and Win-GCC
which take 40-60 and 30-50 minutes including FATE (but only partial FATE due to
the pending patchset for subtitle refs). The Win-MSVC-CLang took 50min (but I don't
know the range yet).

FATE takes about 2/3 of the time, so when adding Win-MSVC-CLang it would be good
to have at most 2 of the - then 3 - Windows builds also running FATE. I'm not sure
which of them would be the least important - maybe Win-GCC, because it's closest
to the Linux FATE build and Windows-specific issues would be detected with Win-MSVC
and Win-MSVC-CLang anyway?

Thanks,
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".

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

[Kacper Michajlow]

On Tue, 17 Jun 2025 at 20:54, softworkz . <softworkz@hotmail.com> wrote:
>
>
> > -----Original Message-----
> > From: Kacper Michajlow <kasper93@gmail.com>
> > Sent: Tuesday, June 17, 2025 6:36 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
>
> [..]
>
> > > > > 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.
>
> It still needs MSYS2 for the Gnu build system, but yea, I get the point of
> using the platform SDK directly.

For the build system if you use 3rd-party meson port
https://gitlab.freedesktop.org/gstreamer/meson-ports/ffmpeg you can
compile ffmpeg without MSYS2. This is handy, especially for
dependencies, because you can build them as subprojects, which
simplifies things. But MSYS2 mingw package manager is handy, because
you don't need to build everything yourself.

> How's the resulting binaries' performance? I'm using the SMP project
> generator which allows you to actually work and debug in VS like with
> any other MSVC project/solution, but for production compiles, that's
> not an option as it's way slower than the GCC/MSYS2/mingw path..

It's Clang/LLVM, basically the same compiler as when using mingw path.
In theory performance should be "the same", of course in case of mingw
you have some parts of C runtime from mingw, so things are different.
We had this problem where llvm-mingw was using custom math functions
which were significantly slower than UCRT ones, but this has been
resolved, just an example.

That's also the main advantage of using Clang, because MSVC has its
own limitations and performance difference. It's good that it builds,
but it has always been better to avoid it :)

GCC vs Clang performance is another story.

If you want to debug in VS/windbg. You can create PDB files even from
llvm-mingw build. All you need is cflag `-gcodeview` and ldflag
`-Wl,-pdb=` (empty will use target name). And then you can load such
binaries in VS with debug info without an issue. LLVM is nice like
that because it supports both GNU and MSVC worlds and many things are
just interchangeable.

> > 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.
>
> Now that andriy/make_x86 is active again, I can disable softworkz/make_linux_x64,
> which is almost the same. The mac run is the fastest and of no concern, Linux-shared
> and Linux-out-of-tree don't run FATE. The heavy-weights are Win-MSVC and Win-GCC
> which take 40-60 and 30-50 minutes including FATE (but only partial FATE due to
> the pending patchset for subtitle refs). The Win-MSVC-CLang took 50min (but I don't
> know the range yet).
>
> FATE takes about 2/3 of the time, so when adding Win-MSVC-CLang it would be good
> to have at most 2 of the - then 3 - Windows builds also running FATE. I'm not sure
> which of them would be the least important - maybe Win-GCC, because it's closest
> to the Linux FATE build and Windows-specific issues would be detected with Win-MSVC
> and Win-MSVC-CLang anyway?

I would say the main thing is testing Win-MSVC to see if things work
in the MSVC world. Win-MSVC-Clang is very similar to GNU-Clang in
terms of driver part, but uses MSVC sysroot. It's oversimplified, but
in practice it uses GNU style frontend, as opposed to clang-cl/cl
using MSVC style. Therefore most issues are in the build system or in
platform specific defines. Like we had a linking issue
https://ffmpeg.org/pipermail/ffmpeg-devel/2025-June/345029.html or
this graph.css embedding issue. So it's nice to test, but at the same
time I don't expect huge breakage in this specific configuration,
probably only build related.

- 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-request@ffmpeg.org with subject "unsubscribe".