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@winehq.org Reporter: depaoli.renzo@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
http://bugs.winehq.org/show_bug.cgi?id=58500
--- Comment #1 from Renzo de Paoli depaoli.renzo@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
http://bugs.winehq.org/show_bug.cgi?id=58500
--- Comment #2 from Renzo de Paoli depaoli.renzo@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.
http://bugs.winehq.org/show_bug.cgi?id=58500
--- Comment #3 from Renzo de Paoli depaoli.renzo@gmail.com --- Created attachment 78959 --> http://bugs.winehq.org/attachment.cgi?id=78959 "make" logfile
The "make" process completes without any issues.
http://bugs.winehq.org/show_bug.cgi?id=58500
--- Comment #4 from Renzo de Paoli depaoli.renzo@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"
http://bugs.winehq.org/show_bug.cgi?id=58500
--- Comment #5 from Renzo de Paoli depaoli.renzo@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.
http://bugs.winehq.org/show_bug.cgi?id=58500
Renzo de Paoli depaoli.renzo@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
http://bugs.winehq.org/show_bug.cgi?id=58500
--- Comment #6 from Alexandre Julliard julliard@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.
http://bugs.winehq.org/show_bug.cgi?id=58500
--- Comment #7 from Renzo de Paoli depaoli.renzo@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.
http://bugs.winehq.org/show_bug.cgi?id=58500
--- Comment #8 from Alexandre Julliard julliard@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.
http://bugs.winehq.org/show_bug.cgi?id=58500
--- Comment #9 from Renzo de Paoli depaoli.renzo@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.
http://bugs.winehq.org/show_bug.cgi?id=58500
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |9f0829497211d769152efd1b74d | |c8908b6af0fc6
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- Hopefully fixed by 9f0829497211d769152efd1b74dc8908b6af0fc6.
http://bugs.winehq.org/show_bug.cgi?id=58500
--- Comment #11 from Renzo de Paoli depaoli.renzo@gmail.com --- (In reply to Alexandre Julliard from comment #10)
Hopefully fixed by 9f0829497211d769152efd1b74dc8908b6af0fc6.
Thanks Alexandre.