Re: [PATCH] parisc: futex: Use same lock set as lws calls

[John David Anglin <dave.anglin@bell.net>]

On 10/18/2011 5:33 AM, Domenico Andreoli wrote:
> Unfortunately I've never been able to build eglibc with the supposed
> fix, indeed I'm running an hacked udev on libc 2.11.something.
>
> BTW, how did you successfully build it? you said you build a good part
> of unstable, I would like to do the same and maybe upload some key
> packages...
>
The dependency issues have been somewhat tricky.  I recall that I did my 
initial
2.13 build with my own tool chain builds (binutils and gcc).  I wanted 
to ensure that
I had the binutils fix for non equivalent aliases.  There were also some 
compiler
fixes that I wanted.

Carlos sent me his current glibc patch set and I integrated them into 
the 2.13-10
patches.  I could send you my current two patches tonight.  Carlos also 
has these
updates.  This wasn't completely straight forward as there were some 
conflicts
with the existing patch set.  The main goal was to fix a bug in thread stack
allocation (tst-timer1?).

I used 2.13-10 as my starting source for applying Carlos' changes.  I 
had built
2.13-13 previously, but I removed the source.  I had tried building and 
installing
2.13-14.  However, it wouldn't install without breaking my installed 
version of perl.
So, I had to go back to 2.13-10.

Once I had the glibc multiarch support installed, then I built the 
latest unstable
versions of binutils, gcc-4.4, gnat-4.4, gcj-4.4, gcc-4.5, gcc-4.6, 
etc.  I'm still using
gcc-4.4 as my default.

Next, I had to update perl and python.  This involved updating a bunch 
of libraries.
There was more than one dependency loop where I had to force 
installation of a
library because I needed it to build the library that the installation 
depended on.

Part of the problem is I was starting from a system updated to 
testing/unstable.
Many of the "-dev" packages for libraries had disappeared as newer versions
were built and uploaded to the servers.  I couldn't really go back 
without breaking
a huge amount of stuff.

So, I just plunged forward.  It's not really possible to support GCC 
without having
the new stuff in unstable.

I have kept all my .deb files and can provide them if needed.

I had hoped that we would get a buildd going by now.  If we wait much 
longer,
the dependencies will be a killer.

Based on my experience, a fair number of packages need some manual
intervention to get them to build.  For example, with glibc, it probably 
is necessary
to disable testsuite checking.  With perl and python, it may be 
necessary to manually
kill tests that  hang, etc.

Dave

-- 
John David Anglin    dave.anglin@bell.net