Re: Ubuntu 12.04 (version#2, drop previous mail)
This is because you _cannot_ install the 32-bit -dev packages onto 12.04. It's not just symlinks that are missing, many of the header files are different between the arches. I'm not sure this is a generic rule, and if it were, then exclusion between i386 and x86_64 should be defined on most dev packages, and it's not the case also note, that in some cases, arch specific headers are moved to arch dependent directories (e.g. jpeg, glib...), which should also parallel install of multi-arch libs in any case, the job by ubuntu folks in 12.04 done is crappy, to say the least
Just do the chroot. You will save yourself so much grief and it will actually work. if the ubuntu folks keep this state of mind, then they'll continue to sink the best solution is then to pick up another distro A+
-- -- Eric Pouech
On Mon, Apr 30, 2012 at 10:37 AM, Eric Pouech <eric.pouech(a)orange.fr> wrote:
This is because you _cannot_ install the 32-bit -dev packages onto 12.04. It's not just symlinks that are missing, many of the header files are different between the arches. I'm not sure this is a generic rule, and if it were, then exclusion between i386 and x86_64 should be defined on most dev packages, and it's not the case also note, that in some cases, arch specific headers are moved to arch dependent directories (e.g. jpeg, glib...), which should also parallel install of multi-arch libs in any case, the job by ubuntu folks in 12.04 done is crappy, to say the least
Just do the chroot. You will save yourself so much grief and it will actually work. if the ubuntu folks keep this state of mind, then they'll continue to sink the best solution is then to pick up another distro A+
+1. One of the reasons I stopped contributing to Wine is that it became too hard to set up 32 bit dev libraries on a 64 bit Ubuntu 11.10 system with its broken multiarch. I was hoping it would be fixed in 12.04, but if it's so broken now that we have to use a chroot, then I might as well use FreeBSD where chroot has always been the only way. Damjan Jovanovic
On 4/30/12 1:37 AM, Eric Pouech wrote:
This is because you _cannot_ install the 32-bit -dev packages onto 12.04. It's not just symlinks that are missing, many of the header files are different between the arches. I'm not sure this is a generic rule, and if it were, then exclusion between i386 and x86_64 should be defined on most dev packages, and it's not the case also note, that in some cases, arch specific headers are moved to arch dependent directories (e.g. jpeg, glib...), which should also parallel install of multi-arch libs in any case, the job by ubuntu folks in 12.04 done is crappy, to say the least
Some context would help here: In previous Ubuntus we ran into quite a few bugs (eg Wine's mpeg123 issues) that occurred because we used a "64-bit header file" with a 32-bit library and .so symlink. This in turn was because the package manager did not have a concept of foreign-architectures -- 32-bit support on Ubuntu64 was done by installing a giant omni-package called ia32-libs that contained every library that might ever be useful (plus some .so links). Things are _much_ better in 12.04. Wine can actually be built and installed biarch as a user package! Ubuntu users are, for the first time, actually using 64-bit Wine when possible because the package manager understands multiarch and, more importantly, because the underlying libraries are coinstallable with themselves. This was not done for the -dev packages yet due to lack of time -- getting the actual libraries in users hands so programs like Wine can work was much more important. So some foo-dev:i386 will install, but will erase foo-dev:amd64. 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.
Just do the chroot. You will save yourself so much grief and it will actually work. if the ubuntu folks keep this state of mind, then they'll continue to sink the best solution is then to pick up another distro A+
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. Thanks, Scott Ritchie
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 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 -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
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
participants (3)
-
Damjan Jovanovic -
Eric Pouech -
Scott Ritchie