Re: Ubuntu 12.04 (version#2, drop previous mail)

2012-05-08 Thread 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.




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




Re: Ubuntu 12.04 (version#2, drop previous mail)

2012-05-01 Thread Eric Pouech


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.



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;
+chartmp[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)





Re: Ubuntu 12.04 (version#2, drop previous mail)

2012-04-30 Thread Scott Ritchie

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




Re: Ubuntu 12.04 (version#2, drop previous mail)

2012-04-30 Thread Damjan Jovanovic
On Mon, Apr 30, 2012 at 10: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
>
>> 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




Re: Ubuntu 12.04 (version#2, drop previous mail)

2012-04-30 Thread Eric Pouech
> 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