From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 30DFB4F546 for ; Tue, 17 Jun 2025 16:36:06 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 1D6C468D4DC; Tue, 17 Jun 2025 19:36:03 +0300 (EEST) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id C557B68C1A0 for ; Tue, 17 Jun 2025 19:35:56 +0300 (EEST) Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-606b6dbe316so12425514a12.3 for ; Tue, 17 Jun 2025 09:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750178156; x=1750782956; darn=ffmpeg.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dYbOBmdHCkc3CEPlAeD2OXDxJk7ky//fOevBAlhq8iQ=; b=HDChn5NhbldXr+1Bzxn5W+aE3RMpCM/7JCbPlxAOCUcX9ihAjWScLAOe6VZQ8jDFv7 kVBl/sT1aJSUlABlufTYnepeJrXFvBJsBDiFOQXA053tdb0rrZT0fO1JQT93iTI94tHG wce9Wr5aPvBm3AraXlbBllMrTp2Ch+mfALpfbrNfQf5nkZc8k3HR9JaMZi68INBoI9BH Kd//ddlztmLqWnN1eoMsuo9TzJzMn+gqSFEl0ciJDf5mUzz3WYosRF/MphrJ2lysaUxc LaTCIHY2taRvzDIEeo0Ukg5Ndwo/t9bdCj+YHXhi/LWzIJJOOTlZ9LnReeOzLk/fwj0D +R/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750178156; x=1750782956; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dYbOBmdHCkc3CEPlAeD2OXDxJk7ky//fOevBAlhq8iQ=; b=WEKe0rSLPgSaGo4zn/csG+Z/P+mnC4u3pOsRdoKlmsjafE1EqS1DEFvNlUJ86fIQ66 gjUmd8sqIJEaHLCIQOrXN/QInksufPEGtRxeHVrsx9u7QaEW/DEN1miQH9RUV4bCFouo +GaOoxotLYUUm/p6Nw6CjWpXDu7FxoGhZIOPT08nZSK7T6AhA9YWdwoVVQ0z8l8UsmnB nnny74kYTfcWgQ5iXeSP4YUL/4R89o8Z5BxAQwi7QfHePDH/NF41b3R5LdkyEFgecEPH 5DgyD0I+JZ8vAcQu16tyVtcbX9jvpsP2tziEIGDV6nEGRwz+SAYfZl8pUhcWTFcWe6Kk WQKw== X-Gm-Message-State: AOJu0YyMMr75FN1DpHzXJF6atJrvNkz0NPy02T1NpNgScCSklZ9f25e7 1UVNQSC6qoUvhe3VkFSwRnS09ddoE16hvjoBg8tpBAxHxH5tZKjX/fq1ykHdVbIvzpLDT3N1H5v H9iE9PesB4jGxLMW80/S7hznY2+OtzUU= X-Gm-Gg: ASbGncuhqzK05FLYF9vGzBiZETWcpOMkJDvQ2uhmvkBtI2txTDELPUl/WXCtb+41cWI 2G4uyvnKM/eJkau9SaIgtAk+m5TAEvHDjoC3Kz23Bh3ytxSn7dX40mfP/Xa3AiKR463wXKNTCkq icVZ8Ps8zP/irgtS+oRDoUafmIzCke/aeS4vELHXaDfif/DJW/OvY= X-Google-Smtp-Source: AGHT+IE1UxwExuxmiXOLTppsoGfmGxmwmSEO75ENq82LN8Beag4GxlaK8T+0KdDP9dUKeBWDCU6mnODN0mSXHcZ7s4w= X-Received: by 2002:a05:6402:909:b0:607:19a6:9f1d with SMTP id 4fb4d7f45d1cf-608d08aa3d4mr12131159a12.14.1750178155972; Tue, 17 Jun 2025 09:35:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kacper Michajlow Date: Tue, 17 Jun 2025 18:35:45 +0200 X-Gm-Features: AX0GCFtR1_rJkEEs7yigOr3UFvh2jLEZJ9DzQCcG_Qv6FwiMNmEUXlanJvKYrQc Message-ID: To: "softworkz ." Subject: Re: [FFmpeg-devel] graph.{html,css} embed failure on Windows build X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Cc: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Tue, 17 Jun 2025 at 18:07, softworkz . wrote: > > > > > -----Original Message----- > > From: Kacper Michajlow > > Sent: Tuesday, June 17, 2025 6:00 PM > > To: softworkz . > > Cc: FFmpeg development discussions and patches > devel@ffmpeg.org> > > Subject: Re: graph.{html,css} embed failure on Windows build > > > > On Tue, 17 Jun 2025 at 17:29, softworkz . wrote: > > > > > > > -----Original Message----- > > > > From: ffmpeg-devel On Behalf Of > > > > softworkz . > > > > Sent: Tuesday, June 17, 2025 4:13 PM > > > > To: Kacper Michajlow > > > > Cc: FFmpeg development discussions and patches > > > devel@ffmpeg.org> > > > > Subject: Re: [FFmpeg-devel] graph.{html,css} embed failure on > > > > Windows build > > > > > > > > > > > > > -----Original Message----- > > > > > From: Kacper Michajlow > > > > > Sent: Tuesday, June 17, 2025 4:06 PM > > > > > To: softworkz . > > > > > Cc: FFmpeg development discussions and patches > > > > devel@ffmpeg.org> > > > > > Subject: Re: graph.{html,css} embed failure on Windows build > > > > > > > > > > On Tue, 17 Jun 2025 at 15:10, Kacper Michajlow > > > > > > > > > > wrote: > > > > > > > > > > > > On Tue, 17 Jun 2025 at 04:07, softworkz . > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Kacper Michajlow > > > > > > > > Sent: Sunday, June 15, 2025 12:49 AM > > > > > > > > To: FFmpeg development discussions and patches > > > > > > > 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".