Ticket #19024 (closed defect: invalid)
parrot-1.0.0 fails to install due to libtool
| Reported by: | sean.b.palmer@… | Owned by: | bfulgham@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.7.0 |
| Keywords: | parrot libtool | Cc: | will@…, nslater@… |
| Port: | parrot |
Description
Trying a standard installation of parrot fails:
$ sudo port install parrot [...] /usr/bin/libtool: for architecture cputype (16777223) cpusubtype (3) object: /usr/local/lib/libgcc_s.10.4.dylib malformed object (unknown load command 4) gnumake: *** [blib/lib/libparrot.1.0.0.dylib] Error 1
This is on OS X 1.4 with Xcode 2.2.2, and the latest MacPorts:
$ port version Version: 1.700
Any ideas?
Change History
comment:2 in reply to: ↑ description Changed 4 years ago by sean.b.palmer@…
Replying to sean.b.palmer@…:
This is on OS X 1.4 with Xcode 2.2.2, and the latest MacPorts:
Sorry, this should have read:
OS X 10.4 with Xcode 2.2.1, &c.
comment:3 Changed 4 years ago by macsforever2000@…
- Owner changed from macports-tickets@… to bfulgham@…
- Cc will@… added; sean.b.palmer@… removed
I would suggest upgrading to Xcode 2.5.
comment:4 Changed 4 years ago by sean.b.palmer@…
Xcode 2.5 is no longer available from the Apple Developer Centre.
comment:6 Changed 4 years ago by sean.b.palmer@…
Sorry, I did just manage to find Xcode 2.5, despite it not being linked from the ADC pages anywhere that I could find, nor being featured in any search results for various combinations of Xcode and 2.5 on the same site...
Currently downloading, and hoping it'll work.
comment:7 Changed 4 years ago by blb@…
The problem is you have something (a gcc build?) in /usr/local that's interfering:
/usr/local/lib/libgcc_s.10.4.dylib malformed object (unknown load command 4)
comment:8 Changed 4 years ago by sean.b.palmer@…
The Xcode 2.5 installation worked, so I'm unable to tell now whether just removing the local .dylib file, or something similar, would have worked. Why would the port not be giving priority to /opt in this case? I mean, could it not modify whichever search path is being used so that the local .dylib does not interfere?
At any rate, since upgrading to Xcode 2.5 incurred no difficulties (despite its size and the requirement of registration, which of course is needed for Xcode 2.2.1 anyway) I think it's a reasonable workaround for this problem.
Cc Me!