[Hackage] #318: Library cannnot be used when registered in-place on OS X
#318: Library cannnot be used when registered in-place on OS X ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: Mac OS | ---------------------------------+------------------------------------------ I built and registered a library --inplace using cabal-install on Mac OS X 10.5.4 using cabal-install 0.5.1 and Cabal 1.4.0.1. I was unable to then use the package afterwards. It failed at link-time with: {{{ Linking Main ... ld: in /... blah .../lib/dist/build/lib-0.1.a, archive has no table of contents collect2: ld returned 1 exit status }}} After talking to Beelsebob and dcoutts on #haskell, I used '''ranlib''' on lib-0.1.a, and it worked. According to dcoutts: "it's because we run ranlib when we install it, but not when we first generate it." -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/318 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#318: Library cannnot be used when registered in-place on OS X ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.4.0.1 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.3 | Platform: Mac OS ---------------------------------+------------------------------------------ Old description:
I built and registered a library --inplace using cabal-install on Mac OS X 10.5.4 using cabal-install 0.5.1 and Cabal 1.4.0.1. I was unable to then use the package afterwards. It failed at link-time with:
{{{ Linking Main ... ld: in /... blah .../lib/dist/build/lib-0.1.a, archive has no table of contents collect2: ld returned 1 exit status }}}
After talking to Beelsebob and dcoutts on #haskell, I used '''ranlib''' on lib-0.1.a, and it worked.
According to dcoutts: "it's because we run ranlib when we install it, but not when we first generate it."
New description: I built and registered a library --inplace on Mac OS X 10.5.4 using cabal- install 0.5.1 and Cabal 1.4.0.1. I was unable to then use the package afterwards. Compiling my program failed at link-time with: {{{ Linking Main ... ld: in /... blah .../lib/dist/build/lib-0.1.a, archive has no table of contents collect2: ld returned 1 exit status }}} After talking to Beelsebob and dcoutts on #haskell, I used '''ranlib''' on lib-0.1.a, and it worked. According to dcoutts: "it's because we run ranlib when we install it, but not when we first generate it." -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/318#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#318: Library cannnot be used when registered in-place on OS X ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.4.0.1 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.3 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by duncan): Some OSX person needs to make a decision here. We can call `ar` without the `q` option and it'll be slower but should make the archive index. If we do it, it needs someone to test. Volunteers please. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/318#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#318: Library cannnot be used when registered in-place on OS X ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.4.0.1 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.3 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): It turns out that {{{cabal install --inplace}}} doesn't run {{{ranlib}}} either -- the step is skipped completely in {{{Distribution.Simple.GHC.installLib}}} when the {{{copyInPlace}}} flag is set. See also http://hackage.haskell.org/trac/ghc/ticket/3137 -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/318#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#318: Library cannnot be used when registered in-place on OS X ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.4.0.1 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.3 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by duncan): Replying to [comment:4 guest]:
It turns out that {{{cabal install --inplace}}} doesn't run {{{ranlib}}} either -- the step is skipped completely in {{{Distribution.Simple.GHC.installLib}}} when the {{{copyInPlace}}} flag is set.
This would be worth fixing if the decision is that running ranlib each time is too expensive. No OSX person has tried this yet or made a decision as far as I know. I now rather expect that nobody would notice if we did just do it every time. Better than running ranlib is to call `ar` without the `q` flag. On GNU systems the `q` is effectively ignored anyway but on OSX it does make it quicker at the expense of not building the index. So on the basis that a decision is better than no decision, even if as a non-OSX user I'm uninformed, how about we change the way we call ar so it always make the index and then just ask some OSX person to try it (and time it). Still need someone to make the change and test it. Do not wait for me to do it, I do not have the time. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/318#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#318: Library cannnot be used when registered in-place on OS X ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.4.0.1 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.3 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): Simply omitting the -q flag to ar is insufficient. According to the ar man pages, you need also to add the -s flag (to build the index). It can be a modifier, e.g. "ar -rs" says to add/replace the object file, and rebuild the index. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/318#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#318: Library cannnot be used when registered in-place on OS X ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.4.0.1 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.3 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by duncan): Replying to [comment:6 guest]:
Simply omitting the -q flag to ar is insufficient. According to the ar man pages, you need also to add the -s flag (to build the index). It can be a modifier, e.g. "ar -rs" says to add/replace the object file, and rebuild the index.
OK, fine we can do that. It's the same syntax on Solaris and Linux. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/318#comment:7 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#318: Library cannnot be used when registered in-place on OS X ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.4.0.1 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.3 | Platform: Mac OS ----------------------------+----------------------------------------------- Changes (by duncan): * milestone: => Cabal-1.8 Comment: This is a problem for the Haskell Platform source build on OSX because we register packages inplace while building. At some point we'll do the same to allow exes to depend on the lib within the same package. So it needs fixing. Using `ar` without `q` seems like the best approach. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/318#comment:8 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#318: Library cannnot be used when registered in-place on OS X ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.4.0.1 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.3 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by duncan): See http://trac.haskell.org/haskell-platform/ticket/34 -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/318#comment:9 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#318: Library cannnot be used when registered in-place on OS X ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.4.0.1 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.3 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by duncan): So it looks like we should be using the flags `as -r -s -c` on all platforms. According to the GNU, Solaris and OSX man pages these flags are ok. The mingw version of `ar` also seems to support them. The only reason to use the `-q` flag appears to be if we're having to call `ar` many times due to command line length limitations, in which case the first time we should use `-q -c`, the intermediate times `-q` and the final time `-r -s`. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/318#comment:10 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#318: Library cannnot be used when registered in-place on OS X
----------------------------+-----------------------------------------------
Reporter: guest | Owner:
Type: defect | Status: closed
Priority: normal | Milestone: Cabal-1.8
Component: Cabal library | Version: 1.4.0.1
Severity: normal | Resolution: fixed
Keywords: | Difficulty: easy (<4 hours)
Ghcversion: 6.8.3 | Platform: Mac OS
----------------------------+-----------------------------------------------
Changes (by duncan):
* status: new => closed
* resolution: => fixed
Comment:
{{{
Sun May 31 20:34:12 BST 2009 Duncan Coutts
#318: Library cannnot be used when registered in-place on OS X ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: closed Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.4.0.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.3 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): With this change, if multiple {{{ar}}} invocations add object files with identical names, only one of these object files is kept in the archive. This can happen if a package has two modules with the same basename and {{{--enable-split-objs}}} is used. Here is a toy script that demonstrates the problem: {{{ # AR="/usr/bin/ar -q -c" AR="/usr/bin/ar -r -s -c" echo 'void f() { }' > a.c gcc -c a.c rm a.a $AR a.a a.o $AR a.a a.o ar -s a.a ar -t a.a }}} To solve this problem, we can go back to using 'ar -q' and then doing a 'ranlib' or 'ar -s' in the end. However, I'd propose that we rename the {{{.o}}} files to have unique names, because that has a better chance of being portable. (For linking, the name of the object file in the archive is immaterial) The problem manifests itself in the form of link errors when using the affected package, like this one: {{{ /opt/ghc-6.11/lib/HTTP-4000.0.7/ghc-6.11.20090605/libHSHTTP-4000.0.7.a(Headers__166.o): In function `sbwI_info': (.text+0xbe): undefined reference to `HTTPzm4000zi0zi7_NetworkziStream_ErrorParse_con_info' }}} I'm using GNU ar of binutils 2.18. I'm not sure whether this is a bug in {{{ar}}} or not. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/318#comment:12 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#318: Library cannnot be used when registered in-place on OS X ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: closed Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.4.0.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.3 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): Oh and this only happens if the duplicate file name is spread over several invocations. If we do this: {{{ AR="/usr/bin/ar -q -s -c" echo 'void f() { }' > a.c gcc -c a.c cp a.o b.o rm a.a $AR a.a a.o b.o b.o $AR a.a a.o ar -s a.a ar -t a.a }}} then we'll end up with a.a containing one copy of {{{a.o}}} and two copies of {{{b.o}}} -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/318#comment:13 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#318: Library cannnot be used when registered in-place on OS X ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: closed Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.4.0.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.3 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): FTR: http://www.opengroup.org/onlinepubs/000095399/utilities/ar.html says "It is unspecified whether multiple files in the archive may be identically named." -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/318#comment:14 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#318: Library cannnot be used when registered in-place on OS X
----------------------------+-----------------------------------------------
Reporter: guest | Owner:
Type: defect | Status: closed
Priority: normal | Milestone: Cabal-1.8
Component: Cabal library | Version: 1.4.0.1
Severity: normal | Resolution: fixed
Keywords: | Difficulty: easy (<4 hours)
Ghcversion: 6.8.3 | Platform: Mac OS
----------------------------+-----------------------------------------------
Comment (by duncan):
Ok so here's a technique that should work:
* For non-OSX, use the same behaviour as we always did (ie up to and
including Cabal-1.6)
* For OSX when we have to use ar multiple times (e.g. when doing split-
objs) we call @ar -q@ for the initial calls and for the final call use @ar
-q -s@.
I've had it confirmed that this works on OSX, it supports duplicates and
creates the index.
{{{
Sun Jun 7 19:05:34 BST 2009 Duncan Coutts
participants (1)
-
Hackage