Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
I've been attempting to build under Mac OS X Mavericks and have run into some problems. My iconv and gmp are installed in non-standard locations using Fink. When configuring http://www.haskell.org/ghc/dist/7.8.1-rc1/ghc-7.8.20140130-x86_64-apple-darw... I get: barneys-imac:ghc-7.8.20140130 bjs$ ./configure --prefix=/Users/bjs/Desktop/ghc --with-iconv-includes=/sw/include --with-gmp-includes=/sw/include --with-iconv-libraries=/sw/lib --with-gmp-libraries=/sw/lib configure: WARNING: unrecognized options: --with-iconv-includes, --with-iconv-libraries and then the installed executable can't itself build ghc from source because of the missing iconv libraries. I noticed that ./configure --help doesn't mention --with-iconv-* in the Mavericks install files but it does in the source build. Any ideas? Cheers, Barney.
I had some similar problems and had to fiddle with my DYLD_LIBRARY_PATH so that ghc-related executables would see the libffi.dylib that comes with GHC before any of my system-wide installed libffi.dylib. Why the permissive @rpath link for libffi.dylib if the GHC executables are supposed to come with their own? On Tue, Feb 4, 2014 at 8:15 AM, Barney Stratford < barney_stratford@fastmail.fm> wrote:
I've been attempting to build under Mac OS X Mavericks and have run into some problems. My iconv and gmp are installed in non-standard locations using Fink. When configuring http://www.haskell.org/ghc/dist/7.8.1-rc1/ghc-7.8.20140130-x86_64-apple-darw... get:
barneys-imac:ghc-7.8.20140130 bjs$ ./configure --prefix=/Users/bjs/Desktop/ghc --with-iconv-includes=/sw/include --with-gmp-includes=/sw/include --with-iconv-libraries=/sw/lib --with-gmp-libraries=/sw/lib configure: WARNING: unrecognized options: --with-iconv-includes, --with-iconv-libraries
and then the installed executable can't itself build ghc from source because of the missing iconv libraries. I noticed that ./configure --help doesn't mention --with-iconv-* in the Mavericks install files but it does in the source build.
Any ideas?
Cheers, Barney. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Feb 5, 2014, at 3:26 PM, Ryan Newton
I had some similar problems and had to fiddle with my DYLD_LIBRARY_PATH so that ghc-related executables would see the libffi.dylib that comes with GHC before any of my system-wide installed libffi.dylib.
Why the permissive @rpath link for libffi.dylib if the GHC executables are supposed to come with their own?
See https://ghc.haskell.org/trac/ghc/ticket/8266 for more information about the dynamic linking on OS X. The reason is two-fold: - During development, the ghc binary, ghc-stage2, lives in 'TOP/inplace/lib/bin', while libffi lives in 'TOP/rts/dist/build'. When deployed, the ghc binary lives in 'TOP/lib/ghc-<version>/bin', while libff lives in 'TOP/lib/ghc-<version>/rts-1.0'. So, the relative paths differ during development and installation, meaning a hard-coded relative path was not an option. - After some iterations, I decided to make OS X behave as much as Linux as possible. Meaning that I just added LC_RPATH's for every library location on which a binary depends. And every library on which binary depend is made @rpath-relative. From the very bottom of the page https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPa... it was my understanding that LC_RPATH were considered first when searching dylibs that had a path starting with @rpath. But apparently that is not the case? Christiaan
participants (3)
-
Barney Stratford -
Christiaan Baaij -
Ryan Newton