where does ghc specify ar options
When bootstrapping cabal-install 0.6.2 on Mac OSX Leopard (Intel), I get a problem when linking: Linking dist/build/cabal/cabal ... ld: in /private/var/folders/mw/mwJSf7ErEa4w8nWyKyyqD++++TY/-Tmp-/zlib-0.5.0.0/dist/build/libHSzlib-0.5.0.0.a, archive has no table of contents This had happened with other ar'chives on my Mac before where it hadn't for some others. In all cases the fix was to make sure ranlib is run on the archive in question, or s is passed to ar during the creation. I have the latest XCode 312m gcc build 5490, and ghc 6.10.1 from MacPorts. In order to ensure ar cr becomes ar crs, I need to find out where in the ghc build process is it known how to create .a files? Where can an "ar cr" be changed to "ar crs" on a system-wide ghc build basis? Cheers, Alexy
On Sun, 2009-03-08 at 22:44 -0500, Alexy Khrabrov wrote:
When bootstrapping cabal-install 0.6.2 on Mac OSX Leopard (Intel), I get a problem when linking:
Linking dist/build/cabal/cabal ... ld: in /private/var/folders/mw/mwJSf7ErEa4w8nWyKyyqD++++TY/-Tmp-/zlib-0.5.0.0/dist/build/libHSzlib-0.5.0.0.a, archive has no table of contents
This had happened with other ar'chives on my Mac before where it hadn't for some others. In all cases the fix was to make sure ranlib is run on the archive in question, or s is passed to ar during the creation. I have the latest XCode 312m gcc build 5490, and ghc 6.10.1 from MacPorts.
In order to ensure ar cr becomes ar crs, I need to find out where in the ghc build process is it known how to create .a files? Where can an "ar cr" be changed to "ar crs" on a system-wide ghc build basis?
We'll need some help from you to investigate this. Cabal does run ranlib on libraries after it installs them. See updateLibArchive in Distribution/Simple/GHC.hs in the Cabal source code. You'll see in the code it looks for ranlib and ar. If neither are available it issues a warning and installs anyway. Perhaps on OSX it should be an error rather than a warning. So we'll want to check that it's really being run when the zlib package is being built. You can run any cabal command with -v or -v3 to see what commands it runs. BTW, how did you get the package installed in that location? Did it involve copying into a temp dir and copying again? I believe that on OSX, copying a .a file breaks the ar index. This is because for reasons best known to themselves Apple decided that the index is only valid if its timestamp is the same as the last modification time of the file. Duncan
BTW, how did you get the package installed in that location? Did it involve copying into a temp dir and copying again? I believe that on OSX, copying a .a file breaks the ar index. This is because for reasons best known to themselves Apple decided that the index is only valid if its timestamp is the same as the last modification time of the file.
OK -- what I did was rather drastic -- I got ar as a part of cctools off Apple's Open Source and verified that it didn't run ranlib on my Leopard 10.5. However it turns out it's supposed to do so -- folks from MacPorts even got a flag -S to make it *not* tun ranlib... Yet they're on PPC, and I'm on Intel (MBP). So what I ended up doing is patching Apple's ar as described in that MacPorts thread: Why ar doesn't call ranlib on Mac? And after that, cabal-install did bootstrap.sh like a charm. I know some folks say that they don't need to run ranlib on their Macs, and some do, and I could have wrapped it in sh-wrappers and investigate it forever, but this issue has re-ar-ed its head often enough that I'm happy with just fetching the li'l slimy ar out of its source soup and fixing it in the bud. Cheers, Alexy
participants (2)
-
Alexy Khrabrov -
Duncan Coutts