> From: Matthias Kilian <[email protected]>
> Date: Thu, Jan 30, 2014 at 10:18 PM
> Subject: lang/ghc (was: i386 build failures)
> To: ports <[email protected]>
>
>
> On Tue, Jan 28, 2014 at 08:36:30PM +0100, Matthias Kilian wrote:
> > > Though OTOH, the port is built with -fno-pie -nopie, so should it even
> > > be necessary to support RELOC_GOTPC? Is it building the internal copy of
> > > gmp
> > > incorrectly or something?
> >
> > After looking at the build logs: yes, there's no trace of no-?pie
> > durinng the build of the bundled libgmp.
> >
> > Also, objdump -r libHSinteger-gmp-0.5.0.0.a shows entries like
> >
> > R_386_GOTPC _GLOBAL_OFFSET_TABLE_
> >
> > for all the object files from gmp.
> >
> > I'll try to fix that part, first (when my current test bulk build
> > finished, may be today or tomorrow).
>
> new trouble happened:
>
> $ ghci
> GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp ... linking ... done.
> Loading package base ...
>
> GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp ... linking ... done.
> Loading package base ...
>
> GHCi runtime linker: fatal error: I found a duplicate definition for symbol
> __i686.get_pc_thunk.bx
> whilst processing object file
> /usr/local/lib/libiconv.a
> This could be caused by:
> * Loading two different object files which export the same symbol
> * Specifying the same object file twice on the GHCi command line
> * An incorrect `package.conf' entry, causing some object to be
> loaded twice.
> GHCi cannot safely continue in this situation. Exiting now. Sorry.
>
> So I've to spend a little bit more work on this :-(
>
> (or touch that fucking rts/Linker.c, but that one is going to die in
> future releases of ghc, anyway, so any work on it is a waste of time)
Please, can commit the diff below?
---8<---
Index: Makefile
===================================================================
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.107
diff -u -p -r1.107 Makefile
--- Makefile 12 Dec 2013 22:13:37 -0000 1.107
+++ Makefile 16 Sep 2014 07:19:03 -0000
@@ -11,7 +11,7 @@ COMMENT-doc = documentation for GHC
DISTNAME = ghc-${MODGHC_VER}
PKGNAME-main = ghc-${MODGHC_VER}
-REVISION-main = 1
+REVISION-main = 2
PKGNAME-doc = ghc-doc-${MODGHC_VER}
REVISION-doc = 0
CATEGORIES = lang devel
@@ -64,6 +64,10 @@ SUPDISTFILES += ${BINDISTFILE-$m}
USE_GMAKE = Yes
USE_GROFF = Yes
+
+.if ${MACHINE_ARCH} == "i386"
+CFLAGS += -fno-pie
+.endif
CONFIGURE_STYLE = gnu
CONFIGURE_ARGS += --with-iconv-includes=${LOCALBASE}/include \
---8<---
With this in, I can have a working ghci to do some Haskell
tests/exercises on my i386-only netbook, using a quick trick.
It does not cause any harm, after all...
The quick dirty trick is:
---8<---
Index: Makefile
===================================================================
RCS file: /cvs/ports/converters/libiconv/Makefile,v
retrieving revision 1.47
diff -u -p -r1.47 Makefile
--- Makefile 9 Nov 2013 23:19:02 -0000 1.47
+++ Makefile 16 Sep 2014 07:19:54 -0000
@@ -3,7 +3,7 @@
COMMENT= character set conversion library
DISTNAME= libiconv-1.14
-REVISION= 1
+REVISION= 2
CATEGORIES= converters devel
MASTER_SITES= ${MASTER_SITE_GNU:=libiconv/}
@@ -21,6 +21,11 @@ WANTLIB= c
BUILD_DEPENDS= devel/gperf
MAKE_FLAGS= INSTALL_DATA=cp
+
+# XXX: unbreak lang/ghc on i386
+.if ${MACHINE_ARCH} == "i386"
+CFLAGS += -fno-pie
+.endif
SEPARATE_BUILD= Yes
CONFIGURE_STYLE= gnu
---8<---
Rebuilding libiconv is faster than rebuilding ghc for sure ;)
Ciao!
David
