[Bug 58500] New: 64-bit "Plain Vanilla Compiling" fails
http://bugs.winehq.org/show_bug.cgi?id=58500 Bug ID: 58500 Summary: 64-bit "Plain Vanilla Compiling" fails Product: Wine Version: 10.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: build-env Assignee: wine-bugs(a)winehq.org Reporter: depaoli.renzo(a)gmail.com Distribution: --- Building Wine-10.12 "64-bit only" shows a number of issues and fails in the end during "make install" when trying to copy a non-existing file. Test-Environment: - Host providing RAMdisk as SharedDrive for build - VirtualBox 7.1.10 r169112 VM with - 8 cores - Debian 12 bookworm 64-bit & KDE - user "vbox" - no previous Wine installation (neither cxoffice or others) - SharedDrive mounted as /home/vbox/RAMdisk -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58500 --- Comment #1 from Renzo de Paoli <depaoli.renzo(a)gmail.com> --- Created attachment 78957 --> http://bugs.winehq.org/attachment.cgi?id=78957 "make install" logfile sudo make install fails with STRIPPROG=x86_64-w64-mingw32-strip ../wine-10.12/tools/install-sh -m 644 programs/msidb/x86_64-windows/msidb.exe /usr/local/lib/wine/x86_64-windows/msidb.exe tools/winebuild/winebuild --builtin /usr/local/lib/wine/x86_64-windows/msidb.exe ../wine-10.12/tools/install-sh -d /usr/local/bin && rm -f /usr/local/bin/msidb && cd /usr/local/bin && cp -pR wine msidb cp: cannot stat 'wine': No such file or directory make: *** [Makefile:302325: programs/msidb/install-lib] Error 1 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58500 --- Comment #2 from Renzo de Paoli <depaoli.renzo(a)gmail.com> --- Created attachment 78958 --> http://bugs.winehq.org/attachment.cgi?id=78958 configure logfiles and generated Makefile The "configure" log files and the "Makefile" appear to be OK, neither errors nor warnings were raised when running the script. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58500 --- Comment #3 from Renzo de Paoli <depaoli.renzo(a)gmail.com> --- Created attachment 78959 --> http://bugs.winehq.org/attachment.cgi?id=78959 "make" logfile The "make" process completes without any issues. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58500 --- Comment #4 from Renzo de Paoli <depaoli.renzo(a)gmail.com> --- Created attachment 78960 --> http://bugs.winehq.org/attachment.cgi?id=78960 logfile - wine 1st start from build folder fails Executing ./wine from the build folder, something that works for Wine-10.0, now fails with "could not load ntdll.so" -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58500 --- Comment #5 from Renzo de Paoli <depaoli.renzo(a)gmail.com> --- Created attachment 78961 --> http://bugs.winehq.org/attachment.cgi?id=78961 logfile - wine 1st start from loader folder works with errors Executing WINEARCH=win64 WINEPREFIX=$HOME/wine.win64.noinst ./wine winecfg from the loader subfolder works, but with some errors. It is unclear, if these errors are "expected" behaviour or are indicating an underlying problem, as neither Building Wine https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine nor Building Biarch Wine On Ubuntu https://gitlab.winehq.org/wine/wine/-/wikis/Building-Biarch-Wine-On-Ubuntu make any mention of them. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58500 Renzo de Paoli <depaoli.renzo(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://dl.winehq.org/wine/ | |source/10.x/wine-10.12.tar. | |xz Keywords| |download, regression, | |source, win64 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58500 --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> --- The underlying problem is that your VM doesn't support ln -s. Obviously that shouldn't break the build, but you still may want to fix that. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58500 --- Comment #7 from Renzo de Paoli <depaoli.renzo(a)gmail.com> --- (In reply to Alexandre Julliard from comment #6)
The underlying problem is that your VM doesn't support ln -s.
Obviously that shouldn't break the build, but you still may want to fix that.
Good afternoon Alexandre. My approach is to keep my test setups as much as possible as "out of the box" (to make it as easy as possible to reproduce). In this case out-of-the-box VirtualBox VM settings. With symbolic linking enabled by - setting host RAMdisk permissions in /etc/fstab RAMdisk /mnt/RAMdisk tmpfs defaults,noatime,mode=1777,size=64G 0 0 - enabling VirtualBox symbolic linking (VM VirtualBox manual chapter 4.3) VBoxManage setextradata "VM-64" VBoxInternal2/SharedFoldersEnableSymlinksCreate/RAMdisk 1 the results are different. Executing wine from the build directory WINEARCH=win64 WINEPREFIX=$HOME/wine.win64.noinst ./wine winecfg works now. The error messages about 'ole' and others are the same as before. "sudo make install" finishes now as well. Running the installed wine WINEARCH=win64 WINEPREFIX=$HOME/wine.win64.inst wine winecfg works, too. In conclusion, it is a problem of the configure script's handling of having no symbolic links available, so your assumption is correct. I guess that leaves 2 options - either remove the "cp -pR" option from the configure script altogether and make it fail early on, - or fix the "cp -pR" option of the configure script and have some extra build test cases that pick up on problems like this. My preference would be the latter, but even the first would be better than the current situation. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58500 --- Comment #8 from Alexandre Julliard <julliard(a)winehq.org> --- The build system can be fixed so that make install works, but note that the filesystem that hosts the WINEPREFIX requires symlink support because of the DOS devices handling. That's probably the failure you got when running from the build tree, and that's not something that can be fixed on the Wine side. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58500 --- Comment #9 from Renzo de Paoli <depaoli.renzo(a)gmail.com> --- (In reply to Alexandre Julliard from comment #8)
The build system can be fixed so that make install works, but note that the filesystem that hosts the WINEPREFIX requires symlink support because of the DOS devices handling. That's probably the failure you got when running from the build tree, and that's not something that can be fixed on the Wine side.
Thanks Alexandre, understood. The Guest VM that builds Wine in this case also hosts the WINEPREFIX after "make install" and is capable of handling symlinks on its own ext4 file system. It just didn't like not being able to create symlinks on the Host's RAMdisk during the build. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58500 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |9f0829497211d769152efd1b74d | |c8908b6af0fc6 --- Comment #10 from Alexandre Julliard <julliard(a)winehq.org> --- Hopefully fixed by 9f0829497211d769152efd1b74dc8908b6af0fc6. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58500 --- Comment #11 from Renzo de Paoli <depaoli.renzo(a)gmail.com> --- (In reply to Alexandre Julliard from comment #10)
Hopefully fixed by 9f0829497211d769152efd1b74dc8908b6af0fc6.
Thanks Alexandre. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58500 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #12 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 10.13. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58500 --- Comment #13 from Renzo de Paoli <depaoli.renzo(a)gmail.com> --- Just to confirm - did a build with 10.14 and that indeed worked fine. Thanks. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla