30 Apr
2012
30 Apr
'12
8:37 a.m.
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
30 Apr
30 Apr
9:01 a.m.
New subject: Ubuntu 12.04 (version#2, drop previous mail)
On Mon, Apr 30, 2012 at 10:37 AM, Eric Pouech <eric.pouech(a)orange.fr> wrote:
+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
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 May
1 May
3:58 a.m.
New subject: Ubuntu 12.04 (version#2, drop previous mail)
On 4/30/12 1:37 AM, Eric Pouech wrote:
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.
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
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+
9:32 a.m.
New subject: Ubuntu 12.04 (version#2, drop previous mail)
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)
9 May
9 May
6:10 a.m.
New subject: Ubuntu 12.04 (version#2, drop previous mail)
On 5/1/12 2:32 AM, Eric Pouech wrote:
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),
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
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
4392
days inactive
4401
days old
4 comments
3 participants
participants (3)
-
Damjan Jovanovic -
Eric Pouech -
Scott Ritchie