Sorry for my ignorance but..why install with +universal? i didn't use this in any port.
Sudish Joseph <sud...@gmail.com> wrote: >Hi, > >I ran into one problem worth mentioning while recompiling gtk and its >dependencies as universal libraries using macports: the pango port >refused to build with +universal (it fails when trying to merge the >i386 & x86_64 libs). The pango-devel port does work with one small >tweak as described at https://trac.macports.org/ticket/22801. > >Essentially, I had to comment out the "PortGroup muniversal 1.0" line >in the Portfile to get a working universal library for pango. > >-Sudish > >On Mon, Jun 21, 2010 at 5:09 AM, Giuseppe Luigi Punzi ><glpu...@lordzealon.com> wrote: >> I died in more dependencies. One, ige-mac-integration. To avoid possible >> problems I uninstall all ports last night to reinstall full gtk2 with quartz. >> >> For now, i'm solving all of this and I hope to get it working this night. >> >> Sudish Joseph <sud...@gmail.com> wrote: >> >>>Antoine Latter <aslat...@gmail.com> writes: >>>> On Sun, Jun 20, 2010 at 12:53 PM, Giuseppe Luigi Punzi Ruiz >>>> <glpu...@lordzealon.com> wrote: >>>>> Hi again, >>>>> >>>>> Yes, you are right, but now, "cabal install leksah" I get: >>>>> >>> >>>[...] >>> >>>>> Undefined symbols: >>>>> "_iconv_close", referenced from: >>>>> _hs_iconv_close 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) >>>>> "_iconv", referenced from: >>>>> _hs_iconv in libHSbase-4.2.0.0.a(iconv.o) >>>>> ld: symbol(s) not found >>> >>>> This one is a bummer, and I see it all the time when I try to build a >>>> package linked against macports. >>> >>>This is caused by the two libiconv's in the system being >>>ABI-incompatible, sadly. The ghc pkg available for download from >>>haskell.org is linked against the system /usr/lib/libiconv.dynlib, which >>>has iconv_open() as a function. Macports has GNU libiconv which >>>#defines iconv_open to libiconv_open() in /opt/local/include/iconv.h. >>> >>>This then blows up as above when linking against other libraries in >>>macports - the linker pulls in GNU libiconv which lacks the symbols >>>needed as you see above. >>> >>>One workaround is to link GHC itself against the macports version of >>>libiconv (and libgmp) and have cabal-install link all subsequent >>>libraries against macports. I did just that this weekend and now have a >>>working threadscope using the Quartz backend for gtk2, which is very >>>nice (no need to run the X server). >>> >>>Recipe for reproducing this build is included below (and I can also >>>provide the resulting ghc-6.12.3 pkg file if needed). >>> >>>Another possible option is to use Homebrew to install gtk2 and other >>>dependencies. Homebrew prefers to use the system-provided libraries and >>>will not pull in GNU libiconv, so this should work with the existing GHC >>>pkg in theory. I didn't pursue this since the homebrew 'gtk+' package >>>didn't seem to have the option to use Quartz instead of X11 as its >>>backend. >>> >>>Steps for linking the ghc runtime against macports: >>> >>>- Specify EXTRA_CABAL_CONFIGURE_FLAGS in mk/build.mk as mentioned at >>> the bottom of http://www.haskell.org/ghc/download_ghc_6_12_3.html >>> >>> EXTRA_CABAL_CONFIGURE_FLAGS = --extra-include-dirs=/opt/local/include \ >>> --extra-lib-dirs=/opt/local/lib >>> >>>- Use the --with-iconv-* and --with-gmp-* flags when configuring ghc. >>> >>> ./configure --with-iconv-includes=/opt/local/include \ >>> --with-iconv-libraries=/opt/local/lib \ >>> --with-gmp-includes=/opt/local/include \ >>> --with-gmp-libraries=/opt/local/lib >>> >>>- This produces a GHC runtime and libraries linked against macports: >>> >>> % otool -L ghc >>> ghc: >>> /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, >>> current version 5.0.0) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >>> version 125.2.0) >>> /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current >>> version 8.0.0) >>> /opt/local/lib/libgmp.10.dylib (compatibility version 11.0.0, current >>> version 11.1.0) >>> >>> % nm HSbase-4.2.0.2.o | fgrep iconv >>> 001ff7f0 T _hs_iconv >>> 001ff7e0 T _hs_iconv_close >>> 001ff800 T _hs_iconv_open >>> U _libiconv >>> U _libiconv_close >>> U _libiconv_open >>> >>> ghc and included libraries use the macports libiconv, so linking >>> against other libraries in macports (gtk2!) will work. >>> >>>- Have cabal-install use macports as well for packages it installs by >>> editing ~/.cabal/config and setting: >>> >>> extra-include-dirs: /opt/local/include >>> extra-lib-dirs: /opt/local/lib >>> >>>- This gives, for e.g., threadscope linked against macports: >>> >>> % otool -L ~/.cabal/bin/threadscope | egrep '(gtk|iconv)' >>> /opt/local/lib/libgtk-quartz-2.0.0.dylib (compatibility version >>> 2001.0.0, current version 2001.1.0) >>> /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current >>> version 8.0.0) >>> >>>- Note that since the ghc runtime is still in 32-bit i386 mode, we >>> need universal versions of most libraries in macports. Recent >>> versions of macports (1.9 for sure, maybe 1.8) make it simple to >>> switch from an x86_64 library to a universal one: >>> >>> % port install gtk2 +universal >>> >>> This will recompile gtk2 and *all* dependent libraries as universal >>> libraries which is exactly what you need. You can then eliminate any >>> inactive 64-bit libraries with: >>> >>> % port -f uninstall inactive >>> >>>> Here's the last thread about with, with more links and discussion: >>>> >>>> http://thread.gmane.org/gmane.comp.lang.haskell.general/18064/ >>>> >>>> The response by Jean-Marie Gaillourdet has worked for me in the past. >>>> >>>> Antoine >>> >>>Thanks for that link, I didn't think of overriding libiconv on a >>>per-package basis. >>> >>>-Sudish >>
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe