Am 10.03.2011 15:52, schrieb Don Stewart:

Does MacPorts still interact badly with libiconv? (The system and MacPorts versions out of sync, making Haskell unbuildable unless in MacPorts).

ghc from macports was build against macports's iconv, which works fine with gtk2 from macports. The official ghc is linked and links against /usr/lib/libiconv.dylib, which makes a problem as soon as -L/opt/local/lib is added by some cabal package. But this can be fixed by adding -L/usr/lib as first argument to ghc. C.

On Thu, Mar 10, 2011 at 5:50 AM, Christian Maeder wrote:

...

Dear All,

we would appreciate a ghc-7.0.2 distribution package via macports, because we intend to make macports packages based on ghc and gtk+2.0.

Libraries from the Haskell-Platform would be nice, too.

Was macports given up?

Via "port pkg" we want to create binary mac packages, however, these packages are only very basic in that they cannot be uninstalled and do not know about their dependencies. Therefore I would also like how to create proper distribution packages. (links are welcome)

Thanks Christian

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Why does the base package depend on iconv only on macs? iconv is not needed under linux or solaris (unless you install haskeline, which is not in the platform. Cheers Christian omitting iconv results in: Undefined symbols: "_locale_charset", referenced from: _localeEncoding in libHSbase-4.3.1.0.a(PrelIOUtils.o) "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.3.1.0.a(iconv.o) (maybe you meant: _hs_iconv_close) "_iconv", referenced from: _hs_iconv in libHSbase-4.3.1.0.a(iconv.o) (maybe you meant: _hs_iconv_open, _hs_iconv , _hs_iconv_close ) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.3.1.0.a(iconv.o) (maybe you meant: _hs_iconv_open) ld: symbol(s) not found Am 10.03.2011 17:35, schrieb Don Stewart:

And that means you can't mix MacPorts and the Mac HP installer. We might want to make that very clear.

On Thu, Mar 10, 2011 at 6:58 AM, Christian Maeder wrote:

...

Am 10.03.2011 15:52, schrieb Don Stewart:

...

Does MacPorts still interact badly with libiconv? (The system and MacPorts versions out of sync, making Haskell unbuildable unless in MacPorts).

ghc from macports was build against macports's iconv, which works fine with gtk2 from macports.

The official ghc is linked and links against /usr/lib/libiconv.dylib, which makes a problem as soon as -L/opt/local/lib is added by some cabal package. But this can be fixed by adding -L/usr/lib as first argument to ghc.

C.

...

On Thu, Mar 10, 2011 at 5:50 AM, Christian Maeder wrote:

...

Dear All,

we would appreciate a ghc-7.0.2 distribution package via macports, because we intend to make macports packages based on ghc and gtk+2.0.

Libraries from the Haskell-Platform would be nice, too.

Was macports given up?

Via "port pkg" we want to create binary mac packages, however, these packages are only very basic in that they cannot be uninstalled and do not know about their dependencies. Therefore I would also like how to create proper distribution packages. (links are welcome)

Thanks Christian

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Am 11.03.2011 11:32, schrieb Max Bolingbroke:

On 10 March 2011 17:51, Christian Maeder wrote:

...

Why does the base package depend on iconv only on macs? iconv is not needed under linux or solaris (unless you install haskeline, which is not in the platform.

I don't have access to a Linux box to check, but according to the source code iconv should be required on any platform except Win32.

Maybe it is statically linked into the base package. And maybe this could be done on Macs with a locally installed static iconv lib?

Could we do something here to make GHC compatible with either iconv? For example, on OS X we could weakly link base against both iconv_* and libiconv_* and then have the hs_iconv_* functions dispatch to the first non-null function of the two.

No idea.

Alternatively, perhaps it would be sufficient to have bases' "extra-lib-dirs" include /usr/lib/? I guess this would only work if GHC arranges to put -L/usr/lib at the very front of the link line, though.

It did not help to just add "/usr/lib" to library-dirs or "-L/usr/lib" to ld-options of base's package.conf file. Maybe it would help to add /usr/lib to those packages that add /opt/local/lib?

Some sort of solution here would eliminate a lot of pain and suffering on the part of OS X GHC users :-)

I agree, C.

Cheers, Max