cabal: library archive index and Mac OS X?
I've gotten a bug report that Mac OS X complains when trying to link against cabal-generated archives, because it lacks an index:
ghc --make Main -o prog Chasing modules from: Test Compiling Main ( Test.hs, Test.o ) Linking ... ld: archive: /usr/local/lib/uust-1.0/libHSuust-1.0.a has no table of contents, add one with ranlib(1) (can't load from it)
In reading the man page of ranlib (on Linux), it sounds like an optional optimization. It also looks like a "-s" flag to ar will generate the index, so that's easy enough to fix. Can anyone explain to me whether / why Mac OS X needs this index, and whether it'll hurt for any other arches? Should we just pass the -s flag to ar? peace, isaac
Isaac Jones wrote:
I've gotten a bug report that Mac OS X complains when trying to link against cabal-generated archives, because it lacks an index: [...] Can anyone explain to me whether / why Mac OS X needs this index, and whether it'll hurt for any other arches? Should we just pass the -s flag to ar?
Mac OS X needs the index. The -s flag to ar will generate the index just as a separate invocation of "ranlib" will, but there's one big Mac OS X-specific problem: The index stores a time stamp; if the .a file's modification date is newer, then ld will refuse to load from it until you re-run ranlib. This commonly happens when you first build your .a files and then touch their modification date while installing. Cheers, Wolfgang
Wolfgang Thaller
The index stores a time stamp; if the .a file's modification date is newer, then ld will refuse to load from it until you re-run ranlib. This commonly happens when you first build your .a files and then touch their modification date while installing.
Owch. That's some odd behavior; any links to an explanation for why it works that way? Does this happen on other arches? I don't see a cabal-side workaround... maybe GHC should run ranlib before linking? Is there any drawback to that? Are there any flags to ln to change this behavior? peace, isaac
On Sun, 20 Mar 2005 23:54:54 -0800, Isaac Jones
The index stores a time stamp; if the .a file's modification date is newer, then ld will refuse to load from it until you re-run ranlib. This commonly happens when you first build your .a files and then touch their modification date while installing.
Owch. That's some odd behavior; any links to an explanation for why it works that way? Does this happen on other arches?
Any system where ranlib actually does something will probably work this way. With most modern archive formats, ranlib doesn't do anything, but the traditional approach is that it updates the index in the library, and they do it based on timestamps. Dave
Isaac Jones
The index stores a time stamp; if the .a file's modification date is newer, then ld will refuse to load from it until you re-run ranlib. This commonly happens when you first build your .a files and then touch their modification date while installing.
Owch. That's some odd behavior; any links to an explanation for why it works that way? Does this happen on other arches?
Yes, this is exactly the way it works on Solaris as well. Regards, Malcolm
participants (4)
-
David Brown -
Isaac Jones -
Malcolm Wallace -
Wolfgang Thaller