darcs patch: Inline shift in GHC's Bits instances for {Int, Word}{, 8...

[Duncan Coutts]

On Sun, 2006-10-08 at 22:56 -0400, Samuel Bronson wrote:

> Incidentally I would really like an ar(1) that doesn't take forever to
> deal with split objects -- I've had to cancel the ar step almost every
> time during the testing of this patch.

You're not alone! I actually had a patch accepted upstream in GNU
binutils to make this faster - or rather to use less memory. Lots of
Gentoo's users with machines with less than 512Mb of RAM had complained
that building GHC with split-objs caused their builds to run out of
memory when linking libHSbase.a.

So I think that as of binutils 2.17.x, that ar will now 'only' take
100mb when re-generating the symbol index in libHSbase.a rather than
500Mb.

Note that it's not the building the .a file that takes ages, it's
re-generating the index. I have a 100 line Haskell 'ar' prog that builds
libHSbase.a in no time at all, but you still have to call ranlib to
create the symbol index.

http://haskell.org/~duncan/Ar.hs  -- for reading .a files
http://haskell.org/~duncan/Ar2.hs -- for creating .a files

This is actually still a win, since with the normal 'ar' it accepts all
it's arguments on the command line and since libHSbase.a contains 1000's
of .o files, one has to use multiple invocations (eg with xargs) because
of the limit on the length of command lines. And of course on each of
those invocations, GNU ar re-generates the symbol index! (There's really
no way to prevent it from doing that, the quick append mode doesn't and
isn't.) So since it takes about half a dozen invocations, we're wasting
the effort of re-generating the symbol index many times.

So it's faster to:
find . -name '*.o' | ./ar libHSbase.a
ranlib libHSbase.a

than:

find . -name '*.o' | xargs ar cru libHSbase.a


Hmm, maybe I should add that ar code into Cabal...

Duncan "GNU ar hater" Coutts