[Bug 54941] New: Invalid symlinks when building --with-wine64 in a container
https://bugs.winehq.org/show_bug.cgi?id=54941 Bug ID: 54941 Summary: Invalid symlinks when building --with-wine64 in a container Product: Wine Version: 8.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: build-env Assignee: wine-bugs(a)winehq.org Reporter: fcasas(a)codeweavers.com Distribution: --- When building Shared WoW64 wine within a container (e.g. using podman), using the 3 steps listed in the wiki: 1. Enter your 32-bit chroot or container (see above about setting a chroot or container up) 2. Do a completely normal 32-bit build of wine 3. Do a second 32-bit build, still in the chroot, with both your 64-bit build and the tools from your first 32-bit build The 64-bit version of Wine fails to detect the injected 32-bit libraries when run from the host system. Because the injected symlinks point to absolute paths that only make sense within the container and not in the host. wine64$ ll loader/ ... lrwxrwxrwx 1 fcasas fcasas 35 May 15 09:54 wine -> /root/Builds/fxc/wine32 lrwxrwxrwx 1 fcasas fcasas 45 May 15 09:54 wine-preloader -> /root/Builds/fxc/wine32/loader/wine-preloader Since the 32-bit libraries are not detected, the current version of wine falls back to "starting in experimental wow64 mode". This triggers errors such as: 0154:err:environ:init_peb starting L"Z:\\home\\fcasas\\my_exe.exe" in experimental wow64 mode 0154:err:module:load_wow64_ntdll failed to load L"\\??\\C:\\windows\\syswow64\\ntdll.dll" error c0000135 0154:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6f00ec1e when running a 32-bit executable. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=54941 --- Comment #1 from Francisco Casas <fcasas(a)codeweavers.com> --- The workaround is to create a new prefix and manually relativize the symlink paths: wine64/loader$ rm wine-preloader wine64/loader$ ln -s ../../wine32/loader/wine-preloader wine-preloader wine64/loader$ rm wine wine64/loader$ ln -s ../../wine32/loader/wine wine -- 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.
https://bugs.winehq.org/show_bug.cgi?id=54941 Francisco Casas <fcasas(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |wow64 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=54941 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick(a)piezo-forte.be --- Comment #2 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, (What is the logic behind using different file hierarchy structures between the 32-bit and 64-bit parts of the same project?) If you use the same paths in both the 32-bit container and 64-bit host environments, you'll avoid path related inconsistencies. Regards. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=54941 --- Comment #3 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Created attachment 74470 --> https://bugs.winehq.org/attachment.cgi?id=74470 Experimental patch create relative symlinks. Hello, Please test the attached patch. Does it fix the issue or break anything? Regards. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=54941 --- Comment #4 from Francisco Casas <fcasas(a)codeweavers.com> ---
(What is the logic behind using different file hierarchy structures between the 32-bit and 64-bit parts of the same project?)
When working with containers, it is often convenient to mount a directory from the host within the container: podman run -dt --name debian-cont --mount="type=bind,source=/home/fcasas/Builds/,destination=/root/Builds" docker.io/library/debian In this case, I mounted /home/fcasas/Builds/ in /root/Builds (since the container doesn't have the "fcasas" username).
Please test the attached patch.
Does it fix the issue or break anything?
Regards.
I applied the patch and recompiled everything in a fresh directory inside the container. The injected symlinks, which in this case are located in /root/Builds/temp/wine64/loader Still end up with absolute paths: lrwxrwxrwx 1 root root 36 May 16 00:12 wine -> /root/Builds/temp/wine32/loader/wine lrwxrwxrwx 1 root root 46 May 16 00:12 wine-preloader -> /root/Builds/temp/wine32/loader/wine-preloader So in the host system, where the route is /home/fcasas/Builds/temp/wine64/loader they are broken. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=54941 --- Comment #5 from Austin English <austinenglish(a)gmail.com> --- (In reply to Francisco Casas from comment #0)
When building Shared WoW64 wine within a container (e.g. using podman), using the 3 steps listed in the wiki:
1. Enter your 32-bit chroot or container (see above about setting a chroot or container up)
You forgot the link -- 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.
https://bugs.winehq.org/show_bug.cgi?id=54941 --- Comment #6 from Francisco Casas <fcasas(a)codeweavers.com> --- (In reply to Austin English from comment #5)
(In reply to Francisco Casas from comment #0)
When building Shared WoW64 wine within a container (e.g. using podman), using the 3 steps listed in the wiki:
1. Enter your 32-bit chroot or container (see above about setting a chroot or container up)
You forgot the link
The link to the wiki page, right? https://wiki.winehq.org/Building_Wine#Shared_WoW64 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=54941 --- Comment #7 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, Maybe he meant a link to podman? https://podman.io/ (In reply to Francisco Casas from comment #4)
In this case, I mounted /home/fcasas/Builds/ in /root/Builds (since the container doesn't have the "fcasas" username).
It doesn't matter that the username doesn't exist. You may create the /home/fcasas/Builds inside the container and bind directly to it, or make /home/fcasas/Builds as a symlink to /root/Builds. Build from /home/fcasas/Builds in the container. With everything in place just like on the host you should get the right paths. (In reply to Francisco Casas from comment #4)
I applied the patch and recompiled everything in a fresh directory inside the container.
The injected symlinks, which in this case are located in
/root/Builds/temp/wine64/loader
Still end up with absolute paths:
I forgot to say that you have to run autoconf after applying the patch. Did you? Regards. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=54941 --- Comment #8 from Francisco Casas <fcasas(a)codeweavers.com> --- (In reply to Olivier F. R. Dierick from comment #7)
It doesn't matter that the username doesn't exist. You may create the /home/fcasas/Builds inside the container and bind directly to it, or make /home/fcasas/Builds as a symlink to /root/Builds. Build from /home/fcasas/Builds in the container. With everything in place just like on the host you should get the right paths.
Yes, that is an easy solution, but the user has to be aware of it. If we keep it, I suggest we mention this in the "Containers" section of the "Building Wine" wiki page. Using relative paths may be better though, since it would also allow the user to move their build folders to another directory (as long as it is the same for all of them). (In reply to Olivier F. R. Dierick from comment #7)
(In reply to Francisco Casas from comment #4)
I applied the patch and recompiled everything in a fresh directory inside the container.
The injected symlinks, which in this case are located in
/root/Builds/temp/wine64/loader
Still end up with absolute paths:
I forgot to say that you have to run autoconf after applying the patch. Did you?
Yes, I configured and build everything from scratch in another directory, starting solely from a fresh copy of the wine source code with the patch applied. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=54941 --- Comment #9 from Francisco Casas <fcasas(a)codeweavers.com> --- Oh, sorry, I thought that with "autoconf" you meant, executing the "./configure" script in the build folder(s), not running "autoconf" in the source code folder. I see that I was missing that. Let me retry the whole process. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=54941 --- Comment #10 from Francisco Casas <fcasas(a)codeweavers.com> --- Hello, I confirm that your patch fixes the problem and the generated symlinks are relative. Indeed, it wasn't working for me because I didn't run "autoconf" after applying the patch (I am still not very familiarized with autotools). Cheers! -- 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