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