GHC 7.4.2 on Ubuntu Trusty

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

GHC 7.4.2 on Ubuntu Trusty

Herbert Valerio Riedel-3
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

Reply | Threaded
Open this post in threaded view
|

GHC 7.4.2 on Ubuntu Trusty

Edward Z. Yang
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

Reply | Threaded
Open this post in threaded view
|

integer-gmp2 issues on Solaris/SPARC

Karel Gardas
In reply to this post by Herbert Valerio Riedel-3

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


Reply | Threaded
Open this post in threaded view
|

integer-gmp2 issues on Solaris/SPARC

Herbert Valerio Riedel-3
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 <gmp.h> header differ? can you create a simple C program
that calls the mpn_andn operation and compare how linkage differs?

Cheers,
  hvr

Reply | Threaded
Open this post in threaded view
|

integer-gmp2 issues on Solaris/SPARC

Karel Gardas
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<gmp.h>  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 <gmp/gmp.h>

#include <stdlib.h>


int
main()
{
     __gmpn_andn_n((mp_limb_t*)NULL, (const mp_limb_t*)NULL, (const
mp_limb_t*)NULL, (mp_size_t)1);
     return 0;
}


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?

Thanks!
Karel

Reply | Threaded
Open this post in threaded view
|

integer-gmp2 issues on Solaris/SPARC

Herbert Valerio Riedel-3
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-Functions

but not in

 https://gmplib.org/manual-4.3.2/Low_002dlevel-Functions.html#Low_002dlevel-Functions


[...]

> 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

Reply | Threaded
Open this post in threaded view
|

integer-gmp2 issues on Solaris/SPARC

Karel Gardas
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