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 94E61465BC for ; Tue, 17 Jun 2025 23:14:53 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 5186F68D941; Wed, 18 Jun 2025 02:14:49 +0300 (EEST) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 4D8F868C30B for ; Wed, 18 Jun 2025 02:14:42 +0300 (EEST) Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-60789b450ceso12206801a12.2 for ; Tue, 17 Jun 2025 16:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750202081; x=1750806881; 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=1JSLlWhXtC29x0MJ02cNhSi+klSMHlW2PMEyX64vQt4=; b=Lm1717X7scDoMtRAn4DLeX8GEx82QOg/CrSLZMvxf4ftqm0013IIa9sQ88S45vxZqI DOV0i2M9ytWn8JCATd5OtEoThO92uufSfgs1v7OcRNDee0FO4564Os6Bv3B/B6TNHwA+ oBoJZWKc/6a7COnSyIvOT9lnYdTYcKUC8oL6FYStUiKmwF9i+aOOP/vtGEPXKy9Vm4MN On4IQg7CTQKEBNKgurK8JCTGrSa+PK84wQfUWlgInhwFxwpYvpSaGxqtmmRXwwt4dvDY GdaNsiC1HfvSau3xeZY9e00pD6gwBjqtcpr1GlGtfnQDxk1CshcSnauz2lVPf8qiuT5d uZKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750202081; x=1750806881; 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=1JSLlWhXtC29x0MJ02cNhSi+klSMHlW2PMEyX64vQt4=; b=jOd5omZOaZpu/deqmdgzJ1QhTx652y3hYxqpG5uCl1Nyi5zmucf3gARi5i1TlmiYGT 5u1zGnRoSDHQqcFqfPQcGkEMoD/kmsLOcc8qGWaywkWepIyhWnUBpNiFArj227W3qY9S 0KKtND6ww7nnlZphl3xBpZ4GqIDbAZsDwrQvxuTb3MZJG8SzBZea8BxGNuhFmk2eVPyA mnfD+pzGZKuPi42nefgeCoo0Cvg6lgEsSqIuqqUAtWYSpKUcNjjVzFn6ajNa57bYu5Kl RQ/QbZozUsiJcrPc/3CdQTo/2VZY5la8zX83MPXGyTuP/x0EjHlbyOCZ1wd66E1LGpXZ 5NoQ== X-Gm-Message-State: AOJu0Yx0hweOEVZt+hNLWj4T1EhOzDmAAkXgOOABM63zi2OsVrISKsvy dAs4WprsMhbigWtzagXDIsC3rGVUxjIVkHfc+rILPAyXEpKg3mb3sHxMqbOuatCrGqOIeRRnedF kJ8KYTruI/V89c1K3AOLazE/NT8cHCVomLtFx X-Gm-Gg: ASbGncuEULgY+wO0Kz/VUbiJO+uuWH7vDwWTPUg/TW8ocGiuvRXQEVkdepW7i5N4ePu fH+GqldKNe8+NhGk6lobVt3/U00o/jeGlG1/wp+d4ex1ObASJ5OJpO/xCbjgGIoDZUWqV4R81Ct AabfY5763xMopNSvB1xqG0yylfNBD3pxrRg26OG3Zt X-Google-Smtp-Source: AGHT+IFb555rPvcae2bqTp/6pqk3/YKHHxwdgw3wbo3IwoltZtb4iugtAIimeLyZbPaIoE9X16rK2Tea1lEZrfvnGW4= X-Received: by 2002:a05:6402:38b:b0:609:241:1deb with SMTP id 4fb4d7f45d1cf-60902412112mr10058275a12.10.1750202081345; Tue, 17 Jun 2025 16:14:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kacper Michajlow Date: Wed, 18 Jun 2025 01:14:30 +0200 X-Gm-Features: AX0GCFtUi5gz9A6BaT80l2_VhAvn1J7dEXsbOe-4TUM-m4_L26N-IYlPRSekqLE 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 20:54, softworkz . wrote: > > > > -----Original Message----- > > From: Kacper Michajlow > > Sent: Tuesday, June 17, 2025 6:36 PM > > To: softworkz . > > Cc: FFmpeg development discussions and patches > 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".