[Bug 54941] New: Invalid symlinks when building --with-wine64 in a container

[WineHQ Bugzilla]

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: [e-mail]
          Reporter: [e-mail]
      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.

[Bug 54941] Invalid symlinks when building --with-wine64 in a container

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54941

--- Comment #1 from Francisco Casas  ---
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

[Bug 54941] Invalid symlinks when building --with-wine64 in a container

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54941

Francisco Casas  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wow64

[Bug 54941] Invalid symlinks when building --with-wine64 in a container

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54941

Olivier F. R. Dierick  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #2 from Olivier F. R. Dierick  ---
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.

[Bug 54941] Invalid symlinks when building --with-wine64 in a container

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54941

--- Comment #3 from Olivier F. R. Dierick  ---
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.

[Bug 54941] Invalid symlinks when building --with-wine64 in a container

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54941

--- Comment #4 from Francisco Casas  ---
> (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.

[Bug 54941] Invalid symlinks when building --with-wine64 in a container

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54941

--- Comment #5 from Austin English  ---
(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:
> - Enter your 32-bit chroot or container (see above about setting a chroot
>
> or container up)

You forgot the link

[Bug 54941] Invalid symlinks when building --with-wine64 in a container

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54941

--- Comment #6 from Francisco Casas  ---
(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:
> > - 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

[Bug 54941] Invalid symlinks when building --with-wine64 in a container

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54941

--- Comment #7 from Olivier F. R. Dierick  ---
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.

[Bug 54941] Invalid symlinks when building --with-wine64 in a container

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54941

--- Comment #8 from Francisco Casas  ---
(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.

[Bug 54941] Invalid symlinks when building --with-wine64 in a container

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54941

--- Comment #9 from Francisco Casas  ---
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.

[Bug 54941] Invalid symlinks when building --with-wine64 in a container

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54941

--- Comment #10 from Francisco Casas  ---
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!