On Mon, Dec 21, 2009 at 1:38 PM, Tom Tobin wrote:

On Mon, Dec 21, 2009 at 4:32 AM, Conor McBride 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?

On Mon, Dec 21, 2009 at 3:43 PM, Tom Tobin 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

On Mon, Dec 21, 2009 at 8:41 PM, Tom Tobin wrote:

On Mon, Dec 21, 2009 at 4:05 PM, Antoine Latter 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! :-)

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] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

2009/12/22 Aaron Tomb

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.

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] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

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

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

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 wrote:

On Mon, Dec 28, 2009 at 9:03 AM, Aaron Tomb 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.