Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
Building from source alone didn't help, but building from source together with the following extra lines to .cabal/config worked: extra-lib-dirs: /usr/lib extra-lib-dirs: /opt/local/lib This is not an ideal solution because this means that any OS X library will shadow the corresponding Macports library. This could lead to problems if you use a Macports library that has several dependencies one of which is shadowed. HTH On 7 May 2010 22:42, Jason Dagit da...@codersbase.com wrote: On Mon, Dec 28, 2009 at 9:03 AM, Aaron Tomb at...@galois.com wrote: On Dec 22, 2009, at 9:36 PM, wren ng thornton wrote: Aaron Tomb wrote: I've come across the issue with iconv, as well. The problem seems to be that some versions of iconv define iconv_open and some related functions as macros (that then call libiconv_open, etc.), and some versions of iconv have exported functions for everything. In particular, the iconv bundled with OS X (1.11) defines iconv_open, but the iconv installed with MacPorts (1.13) does not. The binary package for GHC 6.12.1 seems to have been compiled on a system without MacPorts, and therefore references iconv_open (etc.) from the Apple-distributed version of the library. If you set up an installation of GHC 6.12 on OS X (I've only tried 10.5) with no references to /opt/local/lib, everything works fine. If you include /opt/local/lib in the extra-lib-dirs field of your .cabal/config file, it tries to link with the MacPorts version and fails with undefined references. Is this a problem with *versions* of iconv, or with branches/forks? If it's versions, then it seems like migrating to =1.13 would be good for everyone. If it's just branches, do you know whether this afflicts Fink users as well as MacPorts users, or should I be the guinea pig to test that? It's a problem with versions. I checked that the official iconv repository does indeed make the change between 1.11 and 1.13 that causes the problem. The issue is that OS X includes an old version. So migrating to =1.13 means convincing Apple to upgrade what they include with the system. If we can accomplish that, I'd be thrilled. But it hasn't happened yet as of 10.6. Fink comes with 1.12. I'm not sure whether 1.12 is more like 1.11 or 1.13. Resurrecting an old thread. I would like to find out: 1. Has there been any update on how to workaround this? 2. Does building 6.12 from macports (or from source on a macports enabled system) fix the problem? It seems like more than just GHC is affected by this, but I'm having trouble digging up solid information on the web about how to workaround it. Many sources (such as stackoverflow) point to this thread so posting a solution here would be a win. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
On Mon, Dec 28, 2009 at 9:03 AM, Aaron Tomb at...@galois.com wrote: On Dec 22, 2009, at 9:36 PM, wren ng thornton wrote: Aaron Tomb wrote: I've come across the issue with iconv, as well. The problem seems to be that some versions of iconv define iconv_open and some related functions as macros (that then call libiconv_open, etc.), and some versions of iconv have exported functions for everything. In particular, the iconv bundled with OS X (1.11) defines iconv_open, but the iconv installed with MacPorts (1.13) does not. The binary package for GHC 6.12.1 seems to have been compiled on a system without MacPorts, and therefore references iconv_open (etc.) from the Apple-distributed version of the library. If you set up an installation of GHC 6.12 on OS X (I've only tried 10.5) with no references to /opt/local/lib, everything works fine. If you include /opt/local/lib in the extra-lib-dirs field of your .cabal/config file, it tries to link with the MacPorts version and fails with undefined references. Is this a problem with *versions* of iconv, or with branches/forks? If it's versions, then it seems like migrating to =1.13 would be good for everyone. If it's just branches, do you know whether this afflicts Fink users as well as MacPorts users, or should I be the guinea pig to test that? It's a problem with versions. I checked that the official iconv repository does indeed make the change between 1.11 and 1.13 that causes the problem. The issue is that OS X includes an old version. So migrating to =1.13 means convincing Apple to upgrade what they include with the system. If we can accomplish that, I'd be thrilled. But it hasn't happened yet as of 10.6. Fink comes with 1.12. I'm not sure whether 1.12 is more like 1.11 or 1.13. Resurrecting an old thread. I would like to find out: 1. Has there been any update on how to workaround this? 2. Does building 6.12 from macports (or from source on a macports enabled system) fix the problem? It seems like more than just GHC is affected by this, but I'm having trouble digging up solid information on the web about how to workaround it. Many sources (such as stackoverflow) point to this thread so posting a solution here would be a win. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
On Dec 22, 2009, at 9:36 PM, wren ng thornton wrote: Aaron Tomb wrote: I've come across the issue with iconv, as well. The problem seems to be that some versions of iconv define iconv_open and some related functions as macros (that then call libiconv_open, etc.), and some versions of iconv have exported functions for everything. In particular, the iconv bundled with OS X (1.11) defines iconv_open, but the iconv installed with MacPorts (1.13) does not. The binary package for GHC 6.12.1 seems to have been compiled on a system without MacPorts, and therefore references iconv_open (etc.) from the Apple-distributed version of the library. If you set up an installation of GHC 6.12 on OS X (I've only tried 10.5) with no references to /opt/local/lib, everything works fine. If you include /opt/local/lib in the extra-lib-dirs field of your .cabal/config file, it tries to link with the MacPorts version and fails with undefined references. Is this a problem with *versions* of iconv, or with branches/forks? If it's versions, then it seems like migrating to =1.13 would be good for everyone. If it's just branches, do you know whether this afflicts Fink users as well as MacPorts users, or should I be the guinea pig to test that? It's a problem with versions. I checked that the official iconv repository does indeed make the change between 1.11 and 1.13 that causes the problem. The issue is that OS X includes an old version. So migrating to =1.13 means convincing Apple to upgrade what they include with the system. If we can accomplish that, I'd be thrilled. But it hasn't happened yet as of 10.6. Fink comes with 1.12. I'm not sure whether 1.12 is more like 1.11 or 1.13. Aaron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
On Dec 21, 2009, at 5:03 PM, Thomas Schilling wrote: It's probably just the search path ordering, no? I.e., if you add something on the command line or in .cabal/config it gets added to the beginning of the search path. Then again, there are cases where you'd want the macports version and others where you'd want the default version. Yes, it's almost certainly just the search path ordering. The problem is to get GHC to use the correct ordering. I've tried exporting LD_LIBRARY_PATH=/usr/lib:/opt/local/lib so that /usr/lib comes first. This doesn't seem to help. And it certainly is true that in some cases you want to prefer the MacPorts version, and in some cases you want to prefer the system version. Do we need some more flexible options to GHC, giving users more control on the ordering of libraries on the linker command line? Aaron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
On Dec 22, 2009, at 10:39 , Aaron Tomb wrote: On Dec 21, 2009, at 5:03 PM, Thomas Schilling wrote: It's probably just the search path ordering, no? I.e., if you add something on the command line or in .cabal/config it gets added to the beginning of the search path. Then again, there are cases where you'd want the macports version and others where you'd want the default version. Yes, it's almost certainly just the search path ordering. The problem is to get GHC to use the correct ordering. I've tried exporting LD_LIBRARY_PATH=/usr/lib:/opt/local/lib On OSX you want DYLD_LIBRARY_PATH. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
On Dec 22, 2009, at 9:33 AM, Brandon S. Allbery KF8NH wrote: On Dec 22, 2009, at 10:39 , Aaron Tomb wrote: On Dec 21, 2009, at 5:03 PM, Thomas Schilling wrote: It's probably just the search path ordering, no? I.e., if you add something on the command line or in .cabal/config it gets added to the beginning of the search path. Then again, there are cases where you'd want the macports version and others where you'd want the default version. Yes, it's almost certainly just the search path ordering. The problem is to get GHC to use the correct ordering. I've tried exporting LD_LIBRARY_PATH=/usr/lib:/opt/local/lib On OSX you want DYLD_LIBRARY_PATH. Ah, right you are. For the record, though, setting DYLD_LIBRARY_PATH doesn't help, either. Aaron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
On Tue, 2009-12-22 at 07:39 -0800, Aaron Tomb wrote: Do we need some more flexible options to GHC, giving users more control on the ordering of libraries on the linker command line? I don't think there is any single ordering that will work. Different packages need libs from different directories. I posted my thoughts about this to the ghc users list: http://haskell.org/pipermail/glasgow-haskell-users/2009-December/018180.html Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
Aaron Tomb wrote: I've come across the issue with iconv, as well. The problem seems to be that some versions of iconv define iconv_open and some related functions as macros (that then call libiconv_open, etc.), and some versions of iconv have exported functions for everything. In particular, the iconv bundled with OS X (1.11) defines iconv_open, but the iconv installed with MacPorts (1.13) does not. The binary package for GHC 6.12.1 seems to have been compiled on a system without MacPorts, and therefore references iconv_open (etc.) from the Apple-distributed version of the library. If you set up an installation of GHC 6.12 on OS X (I've only tried 10.5) with no references to /opt/local/lib, everything works fine. If you include /opt/local/lib in the extra-lib-dirs field of your .cabal/config file, it tries to link with the MacPorts version and fails with undefined references. Is this a problem with *versions* of iconv, or with branches/forks? If it's versions, then it seems like migrating to =1.13 would be good for everyone. If it's just branches, do you know whether this afflicts Fink users as well as MacPorts users, or should I be the guinea pig to test that? -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC 6.12 on OS X 10.5
Hi
I thought I'd record my upgrade exerience (so far) in case anyone else
finds it useful, and (more selfishly) in case anyone has some helpful
advice. Summary of situation
* I got 6.12 working.
* It took a lot of fumbling around.
* The eventual fix (renaming /opt/local/lib/libiconv.dylib)
was a bit dodgy, but is holding for now.
Long rambling narrative follows.
Various features of GHC 6.12 made it very tempting to go for an
earlier upgrade than I normally would. (SHE really needs GADT-style
data families; everything I do needs deriving Traversable (deriving
HalfZip would be nice too!).) Already there was a handy installer for
Intel+Leopard macs (is anybody on the PPC+Leopard case? if not, I will
be soon...). I thought go for it.
Installation, no problem. Compiling something: whoops, no mtl. OK,
cabal install mtl: whoops, no acceptable cabal. Fair dos, if I'd read
the warnings I'd have known that my cabal-install would be useless and
tried to build the new one.
QUESTION: Is the sensible upgrade path to build cabal-install 0.8 with
your old GHC, before installing 6.12? Does this even work? At one
point, I tried this and had some peculiar issues involving zlib...
Anyhow, I've got 6.12 and I need cabal-install 0.8. Can I find it?
Tricky, and http://haskell.org/cabal/ didn't help much. I'm very
tolerant of busy people not quite getting round to it, and I can use
google, so I find the darcs version and get cracking. This happens:
-
bash-3.2$ ./bootstrap.sh
Checking installed packages for ghc-6.12.1...
parsec-2.1.0.1 will be downloaded and installed.
network-2.2.1.5 will be downloaded and installed.
Cabal is already installed and the version is ok.
mtl-1.1.0.2 will be downloaded and installed.
HTTP-4000.0.8 will be downloaded and installed.
zlib-0.5.2.0 will be downloaded and installed.
Downloading parsec-2.1.0.1...
% Total% Received % Xferd Average Speed TimeTime
Time Current
Dload Upload Total Spent
Left Speed
100 15430 100 154300 0 12743 0 0:00:01 0:00:01
--:--:-- 19312
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking Setup ...
Undefined symbols:
_iconv_close, referenced from:
_hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o)
_iconv, referenced from:
_hs_iconv in libHSbase-4.2.0.0.a(iconv.o)
_iconv_open, referenced from:
_hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
Error during cabal-install bootstrap:
Compiling the Setup script failed
-
At lthis point, I suspected a linker/dylib problem, but foolishly, I
wanted the problem to be pretty much anything else, so I spent far too
long looking the wrong way. I thought that if I could just get
cabal-install working somehow, I'd be ok.
I tried installing parsec with runhaskell Setup.hs
{configure,build,install} but each of these commands appeared content
to do precisely nothing: I found this perplexing.
I tried reverting to 6.10.4 and compiling cabal-install. This made
more progress, but died with some sort of zlib version snafu. (I'm
sorry, I should have recorded the details but didn't.) The
zlib-0.5.2.0 package did install successfully, but somehow the build
for cabal-install itself went awry with an even though this is the
right version I can't find X sort of a problem.
I uninstalled 6.10.4, deleted my .cabal directory, nuked a few other
relics
showing up from what's probably a dumb choice of PATH setting. I had
another go at 6.12, and this time I tried compiling a wee program of
my own
with no exciting package dependencies. Should have done that straight
away,
of course. Same iconv problem. This left no alternative. I found I had
a /usr/lib/libiconv.dylib etc and an /opt/local/lib/libiconv.dylib etc,
so I renamed the latter to opt/local/lib/moolibiconv.dylib, and
suddenly,
GHC became capable of linking stuff. The darcs version of cabal-install
then built just fine; SHE rebuilt ok; Epigram needed a few extra
LANGUAGE
pragmas, but no trouble. I'm almost back where I was.
I worry about this.
(1) What have I broken by shifting the opt/local/lib copy of
libiconv?
(2) Why did that break things anyway?
(3) How come I ended up with a broken library setup?
(4) What else is broken? (What's worse than finding a maggot in your
apple? Finding half a maggot in your apple.)
I'm not at all a mac expert (I use a mac because I'm too stupid to
maintain a linux installation -- the Nottingham grad students (all
grown up now) told me they were fed up fixing my computer back in 04.)
This dylib nonsense seems quite common. Is it MacPorts messing things
up? Is there a more principled fix than the brutal thing I did? I
wonder if it might be possible to build some sort of diagnostic tool
to check paths
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
On Mon, Dec 21, 2009 at 4:32 AM, Conor McBride co...@strictlypositive.org wrote: I thought I'd record my upgrade exerience (so far) in case anyone else finds it useful, and (more selfishly) in case anyone has some helpful advice. Summary of situation You just described what I went through last night with GHC 6.12 before giving up and going to bed, except that I'm on Snow Leopard (OS X 10.6). I got the undefined symbols errors when trying to compile cpphs, which came up at some point in the build process when trying to install Happstack via cabal 0.8.0. I was wondering if if something was getting confused between my MacPorts libraries and OS X, and your experience certainly makes it seem that way; I have the MacPorts paths set up in my .cabal/config file as extra-include-dirs and extra-lib-dirs, otherwise I can't get particular libraries (e.g., pcre-lite) to compile. I'm going to wipe my .cabal and .ghc and try from scratch to build as much as possible without the MacPorts paths, only re-adding them for single builds as necessary; I'll write back after I see how that goes. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
On Mon, Dec 21, 2009 at 1:38 PM, Tom Tobin korp...@korpios.com wrote: On Mon, Dec 21, 2009 at 4:32 AM, Conor McBride co...@strictlypositive.org wrote: I thought I'd record my upgrade exerience (so far) in case anyone else finds it useful, and (more selfishly) in case anyone has some helpful advice. Summary of situation You just described what I went through last night with GHC 6.12 before giving up and going to bed, except that I'm on Snow Leopard (OS X 10.6). I got the undefined symbols errors when trying to compile cpphs, which came up at some point in the build process when trying to install Happstack via cabal 0.8.0. I was wondering if if something was getting confused between my MacPorts libraries and OS X, and your experience certainly makes it seem that way; I have the MacPorts paths set up in my .cabal/config file as extra-include-dirs and extra-lib-dirs, otherwise I can't get particular libraries (e.g., pcre-lite) to compile. I'm going to wipe my .cabal and .ghc and try from scratch to build as much as possible without the MacPorts paths, only re-adding them for single builds as necessary; I'll write back after I see how that goes. This time, after wiping .ghc and .cabal, I immediately did cabal update followed by cabal install happstack (without going and changing the extra-include-* settings in .cabal/config to point at the MacPorts dirs). cpphs compiled fine this time, but I got a failure due to haskell-src-exts not building; haskell-src-exts in turn complained that happy wasn't installed. I went and installed happy, then haskell-src-exts (which installed v1.3.4), and then did cabal install happstack again which installed haskell-src-exts v1.0.1 (I guess GHC understands how to deal with two different installed library versions?). This time the install died on HJScript: ** [ 2 of 26] Compiling HJScript.Monad ( src/HJScript/Monad.hs, dist/build/HJScript/Monad.o ) src/HJScript/Monad.hs:51:10: A pattern match on a GADT requires -XGADTs In the pattern: EmptyBlock In the definition of `mappend': mappend EmptyBlock b = b In the instance declaration for `Monoid (Block ())' cabal: Error: some packages failed to install: HJScript-0.4.5 failed during the building phase. The exception was: ExitFailure 1 ** I have no idea what to do next, so I'll probably bring this particular issue up on the Happstack list next. My questions at this point: 1) The original problem definitely looks like it's related to library confusion between the system libs and the MacPorts libs. Is there any way of sanely handling this when I need a library that's available through MacPorts but not OS X's system libs? (MacPorts' insistence on maintaining an entirely separate library stack from the OS X system libraries is starting to make me crazy. ::sigh::) 2) Regarding haskell-src-exts: why wasn't happy wasn't pulled into the dependency graph in the first place? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
not sure if this helps, but try: # ports share lib export export CPATH=~/local/include export LIBRARY_PATH=~/local/lib export LD_LIBRARY_PATH=~/local/lib export DYLD_LIBRARY_PATH=~/local/lib replace ~/local/ with your ports path On Tue, Dec 22, 2009 at 5:43 AM, Tom Tobin korp...@korpios.com wrote: On Mon, Dec 21, 2009 at 1:38 PM, Tom Tobin korp...@korpios.com wrote: On Mon, Dec 21, 2009 at 4:32 AM, Conor McBride co...@strictlypositive.org wrote: I thought I'd record my upgrade exerience (so far) in case anyone else finds it useful, and (more selfishly) in case anyone has some helpful advice. Summary of situation You just described what I went through last night with GHC 6.12 before giving up and going to bed, except that I'm on Snow Leopard (OS X 10.6). I got the undefined symbols errors when trying to compile cpphs, which came up at some point in the build process when trying to install Happstack via cabal 0.8.0. I was wondering if if something was getting confused between my MacPorts libraries and OS X, and your experience certainly makes it seem that way; I have the MacPorts paths set up in my .cabal/config file as extra-include-dirs and extra-lib-dirs, otherwise I can't get particular libraries (e.g., pcre-lite) to compile. I'm going to wipe my .cabal and .ghc and try from scratch to build as much as possible without the MacPorts paths, only re-adding them for single builds as necessary; I'll write back after I see how that goes. This time, after wiping .ghc and .cabal, I immediately did cabal update followed by cabal install happstack (without going and changing the extra-include-* settings in .cabal/config to point at the MacPorts dirs). cpphs compiled fine this time, but I got a failure due to haskell-src-exts not building; haskell-src-exts in turn complained that happy wasn't installed. I went and installed happy, then haskell-src-exts (which installed v1.3.4), and then did cabal install happstack again which installed haskell-src-exts v1.0.1 (I guess GHC understands how to deal with two different installed library versions?). This time the install died on HJScript: ** [ 2 of 26] Compiling HJScript.Monad ( src/HJScript/Monad.hs, dist/build/HJScript/Monad.o ) src/HJScript/Monad.hs:51:10: A pattern match on a GADT requires -XGADTs In the pattern: EmptyBlock In the definition of `mappend': mappend EmptyBlock b = b In the instance declaration for `Monoid (Block ())' cabal: Error: some packages failed to install: HJScript-0.4.5 failed during the building phase. The exception was: ExitFailure 1 ** I have no idea what to do next, so I'll probably bring this particular issue up on the Happstack list next. My questions at this point: 1) The original problem definitely looks like it's related to library confusion between the system libs and the MacPorts libs. Is there any way of sanely handling this when I need a library that's available through MacPorts but not OS X's system libs? (MacPorts' insistence on maintaining an entirely separate library stack from the OS X system libraries is starting to make me crazy. ::sigh::) 2) Regarding haskell-src-exts: why wasn't happy wasn't pulled into the dependency graph in the first place? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- jinjing ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
On Mon, Dec 21, 2009 at 3:43 PM, Tom Tobin korp...@korpios.com wrote:
This time the install died on HJScript:
**
[ 2 of 26] Compiling HJScript.Monad ( src/HJScript/Monad.hs,
dist/build/HJScript/Monad.o )
src/HJScript/Monad.hs:51:10:
A pattern match on a GADT requires -XGADTs
In the pattern: EmptyBlock
In the definition of `mappend': mappend EmptyBlock b = b
In the instance declaration for `Monoid (Block ())'
cabal: Error: some packages failed to install:
HJScript-0.4.5 failed during the building phase. The exception was:
ExitFailure 1
**
I have no idea what to do next, so I'll probably bring this particular
issue up on the Happstack list next.
This one I can help with. You need to modify the .cabal file for
HJScript slightly. To do this:
cabal unpack HJScript
cd HJScript-0.4.5
${EDITOR} HJScript.cabal
And then add 'GADTs' to the 'Extensions:' list.
Antoine
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
I've come across the issue with iconv, as well.
The problem seems to be that some versions of iconv define iconv_open
and some related functions as macros (that then call libiconv_open,
etc.), and some versions of iconv have exported functions for
everything. In particular, the iconv bundled with OS X (1.11) defines
iconv_open, but the iconv installed with MacPorts (1.13) does not. The
binary package for GHC 6.12.1 seems to have been compiled on a system
without MacPorts, and therefore references iconv_open (etc.) from the
Apple-distributed version of the library.
If you set up an installation of GHC 6.12 on OS X (I've only tried
10.5) with no references to /opt/local/lib, everything works fine. If
you include /opt/local/lib in the extra-lib-dirs field of your .cabal/
config file, it tries to link with the MacPorts version and fails with
undefined references.
If you don't have that entry in your .cabal/config, but include the
extra library directory on the command line while installing a
particular package, the library directory will be registered with that
package and added to the search path if you compile a program that
uses that package. This seems to mean that you can't build any Haskell
package that depends on C libraries installed via MacPorts, or the
build will fail with undefined references from the iconv library.
I'm going to do some digging to see whether I can solve this without
modifying GHC.
Aaron
--
Aaron Tomb
Galois, Inc. (http://www.galois.com)
at...@galois.com
Phone: (503) 808-7206
Fax: (503) 350-0833
On Dec 21, 2009, at 2:32 AM, Conor McBride wrote:
Hi
I thought I'd record my upgrade exerience (so far) in case anyone else
finds it useful, and (more selfishly) in case anyone has some helpful
advice. Summary of situation
* I got 6.12 working.
* It took a lot of fumbling around.
* The eventual fix (renaming /opt/local/lib/libiconv.dylib)
was a bit dodgy, but is holding for now.
Long rambling narrative follows.
Various features of GHC 6.12 made it very tempting to go for an
earlier upgrade than I normally would. (SHE really needs GADT-style
data families; everything I do needs deriving Traversable (deriving
HalfZip would be nice too!).) Already there was a handy installer for
Intel+Leopard macs (is anybody on the PPC+Leopard case? if not, I will
be soon...). I thought go for it.
Installation, no problem. Compiling something: whoops, no mtl. OK,
cabal install mtl: whoops, no acceptable cabal. Fair dos, if I'd read
the warnings I'd have known that my cabal-install would be useless and
tried to build the new one.
QUESTION: Is the sensible upgrade path to build cabal-install 0.8 with
your old GHC, before installing 6.12? Does this even work? At one
point, I tried this and had some peculiar issues involving zlib...
Anyhow, I've got 6.12 and I need cabal-install 0.8. Can I find it?
Tricky, and http://haskell.org/cabal/ didn't help much. I'm very
tolerant of busy people not quite getting round to it, and I can use
google, so I find the darcs version and get cracking. This happens:
-
bash-3.2$ ./bootstrap.sh
Checking installed packages for ghc-6.12.1...
parsec-2.1.0.1 will be downloaded and installed.
network-2.2.1.5 will be downloaded and installed.
Cabal is already installed and the version is ok.
mtl-1.1.0.2 will be downloaded and installed.
HTTP-4000.0.8 will be downloaded and installed.
zlib-0.5.2.0 will be downloaded and installed.
Downloading parsec-2.1.0.1...
% Total% Received % Xferd Average Speed TimeTime
Time Current
Dload Upload Total Spent
Left Speed
100 15430 100 154300 0 12743 0 0:00:01 0:00:01
--:--:-- 19312
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking Setup ...
Undefined symbols:
_iconv_close, referenced from:
_hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o)
_iconv, referenced from:
_hs_iconv in libHSbase-4.2.0.0.a(iconv.o)
_iconv_open, referenced from:
_hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
Error during cabal-install bootstrap:
Compiling the Setup script failed
-
At lthis point, I suspected a linker/dylib problem, but foolishly, I
wanted the problem to be pretty much anything else, so I spent far too
long looking the wrong way. I thought that if I could just get
cabal-install working somehow, I'd be ok.
I tried installing parsec with runhaskell Setup.hs
{configure,build,install} but each of these commands appeared content
to do precisely nothing: I found this perplexing.
I tried reverting to 6.10.4 and compiling cabal-install. This made
more progress, but died with some sort of zlib version snafu. (I'm
sorry, I should have recorded the details but didn't.) The
zlib-0.5.2.0 package
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
On Dec 21, 2009, at 17:39 , Aaron Tomb wrote: The problem seems to be that some versions of iconv define iconv_open and some related functions as macros (that then call libiconv_open, etc.), and some versions of iconv have exported functions for everything. In particular, the iconv bundled with OS X (1.11) defines iconv_open, but the iconv installed with MacPorts (1.13) does not. The binary package for GHC 6.12.1 seems to have been compiled on a system without MacPorts, and therefore references iconv_open (etc.) from the Apple-distributed version of the library. Perhaps the best fix for this is to submit an updated GHC port to MacPorts. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
On Dec 21, 2009, at 2:44 PM, Brandon S. Allbery KF8NH wrote: On Dec 21, 2009, at 17:39 , Aaron Tomb wrote: The problem seems to be that some versions of iconv define iconv_open and some related functions as macros (that then call libiconv_open, etc.), and some versions of iconv have exported functions for everything. In particular, the iconv bundled with OS X (1.11) defines iconv_open, but the iconv installed with MacPorts (1.13) does not. The binary package for GHC 6.12.1 seems to have been compiled on a system without MacPorts, and therefore references iconv_open (etc.) from the Apple-distributed version of the library. Perhaps the best fix for this is to submit an updated GHC port to MacPorts. This is certainly a possibility. I believe that a GHC built against MacPorts would work properly on a system with MacPorts installed. However, the downside of that approach is that any binary compiled with such a GHC could _only_ be run on a system with MacPorts installed. I'd love to have a GHC that would play nicely with MacPorts, but not depend on it unless necessary (where necessary means when I use a package that links to a C library only available via MacPorts) Aaron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
2009/12/22 Aaron Tomb at...@galois.com On Dec 21, 2009, at 2:44 PM, Brandon S. Allbery KF8NH wrote: On Dec 21, 2009, at 17:39 , Aaron Tomb wrote: The problem seems to be that some versions of iconv define iconv_open and some related functions as macros (that then call libiconv_open, etc.), and some versions of iconv have exported functions for everything. In particular, the iconv bundled with OS X (1.11) defines iconv_open, but the iconv installed with MacPorts (1.13) does not. The binary package for GHC 6.12.1 seems to have been compiled on a system without MacPorts, and therefore references iconv_open (etc.) from the Apple-distributed version of the library. Perhaps the best fix for this is to submit an updated GHC port to MacPorts. This is certainly a possibility. I believe that a GHC built against MacPorts would work properly on a system with MacPorts installed. However, the downside of that approach is that any binary compiled with such a GHC could _only_ be run on a system with MacPorts installed. I'd love to have a GHC that would play nicely with MacPorts, but not depend on it unless necessary (where necessary means when I use a package that links to a C library only available via MacPorts) It's probably just the search path ordering, no? I.e., if you add something on the command line or in .cabal/config it gets added to the beginning of the search path. Then again, there are cases where you'd want the macports version and others where you'd want the default version. There's another macports related problem: Since GHC is 32bit only even on a 64bit OS X you have to compile every MacPorts module with +universal which goes wrong often enough to break quite many (most?) packages (and dependees). Aaron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
On Mon, Dec 21, 2009 at 4:05 PM, Antoine Latter aslat...@gmail.com wrote:
This one I can help with. You need to modify the .cabal file for
HJScript slightly. To do this:
cabal unpack HJScript
cd HJScript-0.4.5
${EDITOR} HJScript.cabal
And then add 'GADTs' to the 'Extensions:' list.
That fixed it (after then running cabal instal in the unpacked dir).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
On Mon, Dec 21, 2009 at 8:41 PM, Tom Tobin korp...@korpios.com wrote:
On Mon, Dec 21, 2009 at 4:05 PM, Antoine Latter aslat...@gmail.com wrote:
This one I can help with. You need to modify the .cabal file for
HJScript slightly. To do this:
cabal unpack HJScript
cd HJScript-0.4.5
${EDITOR} HJScript.cabal
And then add 'GADTs' to the 'Extensions:' list.
That fixed it (after then running cabal instal in the unpacked dir).
And oh, yes — thanks! :-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 on OS X 10.5
On Mon, 2009-12-21 at 10:32 +, Conor McBride wrote:
QUESTION: Is the sensible upgrade path to build cabal-install 0.8 with
your old GHC, before installing 6.12? Does this even work?
Yes and yes.
Anyhow, I've got 6.12 and I need cabal-install 0.8. Can I find it?
Note that it is now on hackage, though it may not have been when you
first looked. There was a window of a few days between the ghc-6.12.1
and cabal-instal-0.8.0 releases.
I tried installing parsec with runhaskell Setup.hs
{configure,build,install} but each of these commands appeared content
to do precisely nothing: I found this perplexing.
That's fairly odd. Sounds like it might be worth reporting. Perhaps
runhaskell is borked.
I tried reverting to 6.10.4 and compiling cabal-install. This made
more progress, but died with some sort of zlib version snafu. (I'm
sorry, I should have recorded the details but didn't.) The
zlib-0.5.2.0 package did install successfully, but somehow the build
for cabal-install itself went awry with an even though this is the
right version I can't find X sort of a problem.
I know of some problems people bump into with zlib on OSX but this
doesn't immediately match any of them. If you can reproduce this I'd be
interested to know.
For reference, the most common one is that people on OSX 10.6 have
hacked their ghc wrapper script to build 32bit binaries but not realised
they need to do the same for hsc2hs, and then zlib is the first FFI
package they build after that.
I worry about this.
(1) What have I broken by shifting the opt/local/lib copy of
libiconv?
Likely, all the programs installed via macports that depend indirectly
on iconv.
(2) Why did that break things anyway?
Because the macports iconv and the system ones are not compatible. The
ghc base lib is built against the system one, but if /opt/local/lib ends
up on the linker path for whatever reason then when ghc links a program,
the linker will pick up the macports iconv and that of course will fail
to link.
(3) How come I ended up with a broken library setup?
Not quite sure what you mean.
(4) What else is broken? (What's worse than finding a maggot in your
apple? Finding half a maggot in your apple.)
Probably just all the progs installed via macports.
Duncan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
