Created attachment 251393 [details] poudriere build failure log, wine 9.0_2,1, host/jail 1401000, LLVM 18 After upgrading system to 14.1-RELEASE which contains LLVM 18, a decision has been made to switch ports' LLVM to 18 as well. Unsure if it's related, but wine fails to package with the following errors snip: ===> Building packages for wine-9.0_2,1 ===> Building wine-9.0_2,1 pkg-static: Unable to access file /wrkdirs/usr/ports/emulators/wine/work/stage/usr/local/lib/wine/x86_64-unix/acledit.dll.so:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/emulators/wine/work/stage/usr/local/lib/wine/x86_64-unix/aclui.dll.so:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/emulators/wine/work/stage/usr/local/lib/wine/x86_64-unix/activeds.dll.so:No such file or directory (Attaching full build log as well.)
Look like doesn't relate to LLVM. Here's how acledit.dll being compiled on 1303001: gcc13 -m64 -o tools/winegcc/winegcc tools/winegcc/utils.o tools/winegcc/winegcc.o -L/usr/local/lib -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc13 -L/usr/local/lib/gcc13 tools/winegcc/winegcc -o dlls/acledit/acledit.dll.so --wine-objdir . -m64 -mno-cygwin -fPIC -fasynchronous-unwind-tables \ -shared dlls/acledit/acledit.spec -Wb,--prefer-native dlls/acledit/main.o \ dlls/winecrt0/libwinecrt0.a dlls/ucrtbase/libucrtbase.a dlls/kernel32/libkernel32.a \ dlls/ntdll/libntdll.a -L/usr/local/lib -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc13 -L/usr/local/lib/gcc13 tools/winegcc/winegcc -o dlls/acledit/x86_64-windows/acledit.dll --wine-objdir . -m64 -mno-cygwin -fPIC -fasynchronous-unwind-tables \ -Wb,--fake-module -shared dlls/acledit/acledit.spec -Wb,--prefer-native And on 1401000 where it fails: gcc13 -m64 -o tools/winegcc/winegcc tools/winegcc/utils.o tools/winegcc/winegcc.o -L/usr/local/lib -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc13 -L/usr/local/lib/gcc13 tools/winegcc/winegcc -o dlls/acledit/x86_64-windows/acledit.dll --wine-objdir . -b x86_64-windows -Wl,--wine-builtin -shared \ dlls/acledit/acledit.spec -Wb,--prefer-native dlls/acledit/x86_64-windows/main.o \ dlls/winecrt0/x86_64-windows/libwinecrt0.a dlls/ucrtbase/x86_64-windows/libucrtbase.a \ dlls/kernel32/x86_64-windows/libkernel32.a dlls/ntdll/x86_64-windows/libntdll.a --no-default-config
Just to verify: same issue with LLVM 17.
There's may be a sign of bigger issue -- wine-proton failed to package recently with pretty similar issue [0]: ===> Building wine-proton-9.0.1 pkg-static: Unable to access file /wrkdirs/usr/ports/emulators/wine-proton/work/stage/usr/local/wine-proton/lib/wine/i386-windows/libwow64.a:No such file or directory *** Error code 1 [0]: https://pkg-status.freebsd.org/beefy17/data/main-i386-default/p2862186fa097_sd7adf3b47a0/logs/wine-proton-9.0.1.log
(In reply to Anton Saietskii from comment #3) > There's may be a sign of bigger issue -- wine-proton failed to > package recently with pretty similar issue [0]: Let's include Alex then - for wine-proton, which he maintains, and maybe an idea on emulators/wine?
(In reply to Gerald Pfeifer from comment #4) Dunno TBH... I just switched from 13.3R to 14.1R and it failed right away, on the first build, without any changes to wine subdir after last successful build. Then I tried LLVM 17 instead of 18 — no luck. Next was building in 13.3R jail on 14.1R system — still no luck, again without changes to jail since last successful build. Right now I'm doing overnight bulk, after which will reboot to old 13.3R ZFS BE and will run 13.3R jail there — so will basically go back in time when it definitely worked, except for ports tree. My only (kinda stupid) guess is perhaps PLIST_SUB stopped working for some reason?
(In reply to Anton Saietskii from comment #3) > build started at Thu May 16 21:34:24 UTC 2024 You are reading too much into it. I made a mistake in pkg-list, which was promptly fixed. (In reply to Anton Saietskii from comment #1) > After upgrading system to 14.1-RELEASE which contains LLVM 18 You are observing the effect from bug 274542. (Wine flips between PE and non-PE build automatically depending on cross-compiler tests that it runs from the configure script, those builds generate different files).
(In reply to Alex S from comment #6) > You are observing the effect from bug 274542. Interesting... Last successful build was on llvm17-17.0.6_6, just before "install all headers" commit. Perhaps I need to do bisect to be sure. (Please don't suggest using even older LLVM — I can't consider it as a solution due to: 1. I'm really frustrated by sole fact using additional instance of the same compiler already present in base system. 2. 13.3R — LLVM 17, 14.1R — LLVM 18. Even if not considering no. 1, it's kinda weird to use older. 3. LLVM 17 is minimum for Fx and other Gecko ports — so going below that for wine would mean 3 different versions of same compiler, and even more — this wouldn't prevent brooks@ from potential extension of commit to LLVM <17.)
Created attachment 251541 [details] poudriere build failure log, wine 9.0_2,1, host/jail 1303001, LLVM 17 As planned, I did boot 13.3R ZFS BE and re-run build. Fails the same way. Perhaps it's recent commit to LLVM 17 & 18 indeed, but can't prove this right now, so proceeding to 'git bisect'.
Created attachment 251611 [details] 'git bisect' log, 13.3R jail, LLVM 17 Yes, this is commit b21e6b4de126e3a8053c792714456bd8dd3ceefb indeed which broke wine packaging when built with LLVM 17. I guess bisecting with LLVM 18 isn't really required.
So, while we have LLVM 15 as default for ports currently, a decision may be made to extend "install all standard headers" commit to <17. Even if not -- eventually default will be bumped anyway and at some point wine will become broken with default ports LLVM. I'm not sure what would be correct (thus can't propose a patch unfortunately), but here are some ideas on how to deal with this (I tried to put them in order of supposed effort to implement): 1. Just revert "all headers commit" (that what's done on my local branch). 2. Make "install all headers" an option. 3. Use dynamic plist for wine. 4. Drop LLVM entirely and build with GCC only (though I'd prefer to get rid of GCC). 5. Make wine to build same way with and without all standard LLVM headers.
(In reply to Anton Saietskii from comment #10) > So, while we have LLVM 15 as default for ports currently, a decision > may be made to extend "install all standard headers" commit to <17. I believe this would be The Right Thing[TM] to keep things consistent. Alternately LLVM_DEFAULT should move to 16 (which should get this change) or even 17. > Even if not -- eventually default will be bumped anyway and at some > point wine will become broken with default ports LLVM. My understanding is that Wine is not broken as such. Rather LLVM changed, actually fixing an issue, and Wine needs to be adjusted for that. (The default version of LLVM does not have this change yet, so this only arose since your setup is non-standard and/or outside of a clean build environment. Still it was was great you flagged this and helped debug it.) > 1. Just revert "all headers commit" (that what's done on my local branch). That's a valid temporary measure; I don't think it's the right approach for the Ports Collection. > 2. Make "install all headers" an option. That would make things unpredictable for ports like emulators/wine. > 4. Drop LLVM entirely and build with GCC only (though I'd prefer to get > rid of GCC). > 5. Make wine to build same way with and without all standard LLVM headers. 6. Make emulators/wine unconditionally depend on a version of LLVM that unconditionally comes with all standard headers. This is what I'm looking at.
Created attachment 251623 [details] v -1, dirty patch draft (In reply to Gerald Pfeifer from comment #11) > so this only arose since your setup is non-standard and/or outside of > a clean build environment I'd like to emphasize correct terminology. My build environment is indeed: 1. Clean as poudriere guarantees that. 2. Standard as using DEFAULT_VERSIONS is official functionality. Though it just non-default, I wouldn't decline that. Regarding possible solution -- something like attached patch may be used as a draft. Please note that I didn't touch plist here -- I tried and failed because it really huge and I don't have ready solution to sort it properly (and likely this has to be done for 32 and WoW as well).
Created attachment 251624 [details] 'lib/wine' part of plist For reference, this is what wine installs to lib/wine when LLVM provides full header set.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=5f69b17e49a9cc392392e9d91d600a4e48fcb50c commit 5f69b17e49a9cc392392e9d91d600a4e48fcb50c Author: Gerald Pfeifer <gerald@FreeBSD.org> AuthorDate: 2024-06-23 08:06:01 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2024-06-23 08:06:01 +0000 emulators/wine-devel: Update to Wine 9.9 This includes the following changes: - Removal of a number of obsolete features in WineD3D. - Support for new WoW64 mode in ODBC. - Various bug fixes. When trying to build with LLVM 15, which is the current default in the Ports Collection we have been using for a while, we now get the following error: configure: error: Suitable PE cross-compiler not found, PE files won't be built. This is an error since --with-mingw was requested. ===> Script "configure" failed unexpectedly. This is not actually a regression from Wine 9.8 to 9.9; rather Wine now diagnoses this (again) instead of simply proceeding. Luckily our devel/llvm18 and devel/llvm17 ports just recently addressed the situation with commits c56fde6514 on May 28 and b21e6b4de1 on June 12, respectively. Accordingly force the use of at least devel/llvm17. [2] This brings a huge number of changes in terms of pkg-plist. (The emulators/wine port will need similar changes or it'll break with builds of LLVM that contain these changes already in the two ports above. [1]) PR: 279677 [1], 274542 [2] emulators/wine-devel/Makefile | 10 +- emulators/wine-devel/distinfo | 6 +- emulators/wine-devel/pkg-plist | 999 ++++++++++------------------------------- 3 files changed, 243 insertions(+), 772 deletions(-)
(In reply to commit-hook from comment #14) Just curious — does something block usage of 'USES=llvm:min=17,build,noexport'? Looks simpler for me than manual build dep + 'if' to ensure minimum version.
(In reply to Anton Saietskii from comment #15) > Just curious — does something block usage of > 'USES=llvm:min=17,build,noexport'? I simply wanted to get the change in more quickly and minimize risk given what else was already in flux. In the meantime I did some more extensive tests and to fix your original issue - with emulators/wine - am using this approach. Thanks for asking/ pointing this out!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=b65e6c38fd055e913a4ce458d5c774c715a5ea9b commit b65e6c38fd055e913a4ce458d5c774c715a5ea9b Author: Gerald Pfeifer <gerald@FreeBSD.org> AuthorDate: 2024-07-03 12:08:37 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2024-07-03 12:09:54 +0000 emulators/wine: Firmly depend on LLVM 15 Our devel/llvm18 and devel/llvm17 ports (with commits c56fde6514 and b21e6b4de1, respectively) now provide C99 include files.[1] This is a positive and fixes a long standing issue. It significantly changes what Wine builds, though. For emulators/wine-devel we moved to the new world order already; for emulators/wine remain a bit more conservative and stay with status quo ante by firmly using LLVM 15. For most users this won't make any difference since so far we have been using LLVM_DEFAULT which currently stands at ... 15. On the way use the new USES=llvm facility instead of doing things more manually. PR: 279677, 274542 [1] emulators/wine/Makefile | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-)
(In reply to commit-hook from comment #17) With this commit, I will be forced to build two (in fact, three including base) different LLVM versions. Actually everyone who uses any of gecko ports will be forced (since LLVM minimum is 17 for those). Guess I'd need to blacklist wine until this will be properly fixed or patch both llvm (to exclude headers) and wine (to not force specific version).
Could using wine-devel (instead of wine) be an option? I am planning to switch wine to the new/fixed model and LLVM 17, we'll want to give folks some time to test that then, though.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=4beb3216818c58ae4d1d53734957660ee99ecd24 commit 4beb3216818c58ae4d1d53734957660ee99ecd24 Author: Gerald Pfeifer <gerald@FreeBSD.org> AuthorDate: 2024-09-08 04:53:03 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2024-09-08 04:53:04 +0000 emulators/wine: Fix the PE build This requires our devel/llvm17 or later ports which bring full header files. [1] It has major impact on how this port is built and the packaging list, so bump PORTREVISION. PR: 280448, 274542 [1], 279677 [1] emulators/wine/Makefile | 5 +- emulators/wine/pkg-plist | 993 +++++++++++------------------------------------ 2 files changed, 233 insertions(+), 765 deletions(-)