Ubuntu 12.04 (version#2, drop previous mail)

[Scott Ritchie]

On 5/1/12 2:32 AM, Eric Pouech wrote:
>
>> This is the downside people in this thread are complaining about:
>> compiling 32-bit programs on a 64-bit Ubuntu install is now slightly
>> more difficult. However, Wine is currently the _only_ piece of
>> software I've encountered that needs to be built for both arches on
>> the same machine in order to be usable. We are beautiful special
>> snowflakes here: Wine developers who aren't using the build daemons is
>> about the extent of the current use case.
> <snip>
>>
>> I'm beginning to have memories of what happened when we removed gcc
>> from the default install. Setting up a 32-bit chroot for building Wine
>> should not be complicated -- I'll present a script to make it even
>> easier soon. You can build in a single command and even use things
>> like ccache and the like to speed it up.
>>
> to summarize:
> ubuntu doesn't do anything to support developers
> as it implies using ubuntu build daemons, not developers' machine (and
> all the relevant environment)
> as it implies to use chroot even on a multi lib arch => multi arch is
> then for users, not developers
>
> bye bye ubuntu then

If this is a blocker for you then I can't blame you then.

For reference the only successful way to build Wine I'm aware of is
http://wiki.winehq.org/Wine64ForPackagers under the "Alternatives" 
section (ie, manually configuring and building 32 and 64 separately and 
copying files from one into the other.)  You may be able to do that 
without a chroot (or something similar like pbuilder),

>
> for the sake of record (I won't even dare to send it to wine-patches) a
> workaround ubuntu recvmsg breakage in order to get ptrace API to be
> usable on 12.04
>
> diff --git a/dlls/ntdll/server.c b/dlls/ntdll/server.c
> index 8a01d22..6c8e759 100644
> --- a/dlls/ntdll/server.c
> +++ b/dlls/ntdll/server.c
> @@ -1016,6 +1016,37 @@ void server_init_process(void)
> send_server_task_port();
> #endif
> #if defined(__linux__) && defined(HAVE_PRCTL)
> + /* work around Ubuntu's recvmsg breakage */
> + if (!server_pid)
> + {
> + int zfd;
> + struct flock fl;
> + char tmp[4096];
> + strcpy(tmp, wine_get_server_dir());
> + strcat(tmp, "/");
> + strcat(tmp, LOCKNAME);
> +
> + if ((zfd = open( tmp, O_RDONLY )) == -1)
> + fatal_error( "no lock present %s.\n", tmp );
> +
> + fl.l_type = F_WRLCK;
> + fl.l_whence = SEEK_SET;
> + fl.l_start = 0;
> + fl.l_len = 1;
> + if (fcntl( zfd, F_GETLK, &fl ) != -1)
> + {
> + if (fl.l_type == F_WRLCK)
> + {
> + /* the file is locked */
> + fprintf(stderr, "getting server_pid from lock %d\n", fl.l_pid);
> + server_pid = fl.l_pid;
> + }
> + fatal_error( "cannot get pid from lock (lock isn't locked)\n");
> + }
> + else
> + fatal_error( "cannot get pid from lock\n");
> + close(zfd);
> + }
> /* work around Ubuntu's ptrace breakage */
> if (server_pid != -1) prctl( 0x59616d61 /* PR_SET_PTRACER */, server_pid );
> #endif
>

I showed this to the developer who originally wrote the kernel ptrace 
stuff, and indeed this seems like an upstream kernel bug, albeit in 
recvmsg rather than ptrace (also note that the ptrace stuff is now in 
the mainline kernel as well, not just Ubuntu, so you may have found a 
problem that was just exposed in Ubuntu first).

Anyway, I'll follow up on it.  In the meantime I'm pushing your patch in 
a stable release update for Wine (once I test another thing), so thank 
you very much for it.

Thanks,
Scott Ritchie