Re: GHC 7.4.2 on Ubuntu Trusty
Hello Edward, On 2015-01-04 at 08:54:58 +0100, Edward Z. Yang wrote: [...]
There are also some changes to hoopl, transformers and hpc (mostly because their bootstrap libraries.)
...what kind of changes specifically? Once thing that needs to be considered is that we'd require to upstream changes to transformers (it's not under GHC HQ's direct control) for a transformers point(?) release ... and we'd need that as we can't release any source-tarball that contains libraries (which get installed into the pkg-db) that don't match their upstream version on Hackage. Cheers, hvr
For transformers, I needed: diff --git a/Control/Monad/Trans/Error.hs b/Control/Monad/Trans/Error.hs index 0158a8a..0dea478 100644 --- a/Control/Monad/Trans/Error.hs +++ b/Control/Monad/Trans/Error.hs @@ -57,6 +57,10 @@ instance MonadPlus IO where mzero = ioError (userError "mzero") m `mplus` n = m `catchIOError` \_ -> n +instance Alternative IO where + empty = mzero + (<|>) = mplus + #if !(MIN_VERSION_base(4,4,0)) -- exported by System.IO.Error from base-4.4 catchIOError :: IO a -> (IOError -> IO a) -> IO a For hpc, I needed: Build-Depends: - base >= 4.4.1 && < 4.8, + base >= 4.4.1 && < 4.9, containers >= 0.4.1 && < 0.6, directory >= 1.1 && < 1.3, - time >= 1.2 && < 1.5 + time >= 1.2 && < 1.6 For hoopl, I needed: - Build-Depends: base >= 4.3 && < 4.8 + Build-Depends: base >= 4.3 && < 4.9 For the latter two, I think this should be a perfectly acceptable point release. For transformers, we could also just ifdef the Alternative into the GHC sources. Edward Excerpts from Herbert Valerio Riedel's message of 2015-01-04 00:22:28 -0800:
Hello Edward,
On 2015-01-04 at 08:54:58 +0100, Edward Z. Yang wrote:
[...]
There are also some changes to hoopl, transformers and hpc (mostly because their bootstrap libraries.)
...what kind of changes specifically?
Once thing that needs to be considered is that we'd require to upstream changes to transformers (it's not under GHC HQ's direct control) for a transformers point(?) release ... and we'd need that as we can't release any source-tarball that contains libraries (which get installed into the pkg-db) that don't match their upstream version on Hackage.
Cheers, hvr
Hello Herbert, I'm sorry to bother you, but recent GHC HEAD does have issue on Solaris/SPARC platform which shows as undefined symbols during the linkage of stage2 binaries. For example ghc-stage2 link step fails with: Undefined first referenced symbol in file __gmpn_andn_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries/integer-gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_and_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries/integer-gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_ior_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries/integer-gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_xor_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries/integer-gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) ld: fatal: symbol referencing errors. No output written to ghc/stage2/build/tmp/ghc-stage2 All binaries fail with the same set of unresolved symbols. I can tell you that I don't see this issue on Solaris/i386 nor on Solaris/amd64 builds as you can verify here: http://haskell.inf.elte.hu/builders/ I'm talking here about exact Solaris 11.1 on SPARC and Solaris 11.1 on AMD64 box. Both Solarises provide the same version of libgmp: $ uname -p sparc $ ls -la /usr/lib/libgmp.so* lrwxrwxrwx 1 root root 15 Feb 20 1999 /usr/lib/libgmp.so -> libgmp.so.3.5.2 lrwxrwxrwx 1 root root 15 Feb 20 1999 /usr/lib/libgmp.so.3 -> libgmp.so.3.5.2 -r-xr-xr-x 1 root bin 1093328 Sep 19 2012 /usr/lib/libgmp.so.3.5.2 $ $ uname -p i386 $ ls -la /usr/lib/libgmp.so* lrwxrwxrwx 1 root root 15 Oct 18 2012 /usr/lib/libgmp.so -> libgmp.so.3.5.2 lrwxrwxrwx 1 root root 15 Oct 18 2012 /usr/lib/libgmp.so.3 -> libgmp.so.3.5.2 -r-xr-xr-x 1 root bin 878276 Feb 5 2014 /usr/lib/libgmp.so.3.5.2 $ And yet on i386/amd64 the symbol (one from the failing set as an example) __gmpn_andn_n is defined: $ nm /usr/lib/libgmp.so|grep __gmpn_andn_n [86] | 375728| 101|FUNC |GLOB |0 |14 |__gmpn_andn_n but on SPARC it's not: $ nm /usr/lib/libgmp.so|grep __gmpn_andn_n $ Do you have any magical knob which I can switch on to work around this issue by not needing those four symbols above? Thanks! Karel
On 2015-01-18 at 15:42:05 +0100, Karel Gardas wrote:
Hello Herbert,
I'm sorry to bother you, but recent GHC HEAD does have issue on Solaris/SPARC platform which shows as undefined symbols during the linkage of stage2 binaries. For example ghc-stage2 link step fails with:
Btw, what GMP version is that exactly? "GMP 3.5.2" doesn't seem to be an official GMP release? [...]
All binaries fail with the same set of unresolved symbols. I can tell you that I don't see this issue on Solaris/i386 nor on Solaris/amd64 builds as you can verify here: http://haskell.inf.elte.hu/builders/
I'm talking here about exact Solaris 11.1 on SPARC and Solaris 11.1 on AMD64 box. Both Solarises provide the same version of libgmp:
[...]
And yet on i386/amd64 the symbol (one from the failing set as an example) __gmpn_andn_n is defined:
$ nm /usr/lib/libgmp.so|grep __gmpn_andn_n [86] | 375728| 101|FUNC |GLOB |0 |14 |__gmpn_andn_n
but on SPARC it's not:
$ nm /usr/lib/libgmp.so|grep __gmpn_andn_n $
Do you have any magical knob which I can switch on to work around this issue by not needing those four symbols above?
...does the
On 01/18/15 04:05 PM, Herbert Valerio Riedel wrote:
On 2015-01-18 at 15:42:05 +0100, Karel Gardas wrote:
Hello Herbert,
I'm sorry to bother you, but recent GHC HEAD does have issue on Solaris/SPARC platform which shows as undefined symbols during the linkage of stage2 binaries. For example ghc-stage2 link step fails with:
Btw, what GMP version is that exactly? "GMP 3.5.2" doesn't seem to be an official GMP release?
This is version 4.3.2 in both cases.
...does the
header differ?
Unfortunately not. The only difference is in CFLAGS: $ gdiff -u /usr/include/gmp/gmp.h /tmp/gmp.h --- /usr/include/gmp/gmp.h 2014-02-05 14:40:13.405522327 +0100 +++ /tmp/gmp.h 2015-01-19 08:35:38.146637514 +0100 @@ -2231,7 +2231,7 @@ /* Define CC and CFLAGS which were used to build this version of GMP */ #define __GMP_CC "/ws/on11update-tools/SUNWspro/sunstudio12.1/bin/cc" -#define __GMP_CFLAGS "-m64 -xO4 -xchip=generic -Ui386 -U__i386 -xregs=no%frameptr -mt -features=extinl,extensions -xustr=ascii_utf16_ushort -xcsi -xthreadvar=%all -D_STDC_99 -xc99=all -D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1 -D_XPG6 -KPIC -DPIC" +#define __GMP_CFLAGS "-m64 -xO4 -xtarget=ultra2 -xarch=sparcvis -xchip=ultra2 -Qoption cg -xregs=no%appl -W2,-xwrap_int -xmemalign=16s -mt -features=extinl,extensions -xustr=ascii_utf16_ushort -xcsi -xthreadvar=%all -D_STDC_99 -xc99=all -D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1 -D_XPG6 -KPIC -DPIC" /* Major version number is the value of __GNU_MP__ too, above and in mp.h. */ #define __GNU_MP_VERSION 4 Let me also add that the gmp.h file does not define mpn_andn_n symbol at all neither it declare __gmpn_andn_n function! Since both i386 and sparc gmp.h are the same this applies to both.
can you create a simple C program that calls the mpn_andn operation and compare how linkage differs?
No, I'm not able to use "mpn_andn" nor "mpn_andn_n". What I'm able to
use is "__gmpn_andn_n". On i386 this pass with implicitly declared
symbol warning:
gmp_test.c: In function ‘main’:
gmp_test.c:10:5: warning: implicit declaration of function ‘__gmpn_andn_n’
on sparc fails on linkage:
$ gcc -Wall gmp_test.c -lgmp
gmp_test.c: In function ‘main’:
gmp_test.c:10:5: warning: implicit declaration of function ‘__gmpn_andn_n’
Undefined first referenced
symbol in file
__gmpn_andn_n /var/tmp//ccSHaGtf.o
ld: fatal: symbol referencing errors. No output written to a.out
collect2: ld returned 1 exit status
My testing program is:
$ cat gmp_test.c
#include
On 2015-01-19 at 10:25:59 +0100, Karel Gardas wrote: [...]
/* Major version number is the value of __GNU_MP__ too, above and in mp.h. */ #define __GNU_MP_VERSION 4
Let me also add that the gmp.h file does not define mpn_andn_n symbol at all neither it declare __gmpn_andn_n function! Since both i386 and sparc gmp.h are the same this applies to both.
Oh, I just checked the documentation, and `mpn_andn_n()` is only mentioned in the GMP 5.0.x docs https://gmplib.org/manual-5.0.4/Low_002dlevel-Functions.html#Low_002dlevel-F... but not in https://gmplib.org/manual-4.3.2/Low_002dlevel-Functions.html#Low_002dlevel-F... [...]
The big issue here is that i386/solaris gmp library so file provides this __gmpn_andn_n symbol but have not declared it in gmp.h at all in a form of mpn_andn_n define. So basically your: -- void mpn_andn_n (mp_limb_t *rp, const mp_limb_t *s1p, const mp_limb_t *s2p, -- mp_size_t n) foreign import ccall unsafe "gmp.h __gmpn_andn_n" c_mpn_andn_n :: MutableByteArray# s -> ByteArray# -> ByteArray# -> GmpSize# -> IO ()
works on i386, but not on sparc.
Is it possible for you to test for those mpn_ symbols in integrer-gmp2 configure and if they are presented then you can use your __gmpn_andn_n foreigner call?
I'm actually rather considering not using those at all when GMP version is 4.* as they're not part of the official API of GMP 4.x Btw, how long do we need to keep supporting GMP 4.x (as it lacks a few other features)? GMP 5.0.0 has been released over 5 years ago... :-/ Cheers, hvr
On 01/19/15 10:54 AM, Herbert Valerio Riedel wrote:
Is it possible for you to test for those mpn_ symbols in integrer-gmp2 configure and if they are presented then you can use your __gmpn_andn_n foreigner call?
I'm actually rather considering not using those at all when GMP version is 4.* as they're not part of the official API of GMP 4.x
Btw, how long do we need to keep supporting GMP 4.x (as it lacks a few other features)?
GMP 5.0.0 has been released over 5 years ago... :-/
It depends on support policy. Speaking about RHEL 6.x and Solaris 11.x, both are supported till 2020 respectively till 2022. If however we support only newest version line of the OS, then RHEL 7.x is already in public (supporting gmp 5.x) but Solaris 12 not. Solaris 12 will probably be released sometimes in 2016 (following Oracle's SPARC/Solaris roadmap). My hope is, this will include gmp 5.x too. Are you ok waiting another year or two for transition? Thanks! Karel
participants (3)
-
Edward Z. Yang -
Herbert Valerio Riedel -
Karel Gardas