GHC | 1 May 12:41 2010

Re: #4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while relocating object file

#4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while
relocating object file
-------------------------+--------------------------------------------------
    Reporter:  igloo     |        Owner:                     
        Type:  bug       |       Status:  new                
    Priority:  highest   |    Milestone:  6.14.1             
   Component:  Compiler  |      Version:  6.13               
    Keywords:            |   Difficulty:                     
          Os:  MacOS X   |     Testcase:                     
Architecture:  x86       |      Failure:  Building GHC failed
-------------------------+--------------------------------------------------

Comment(by thorkilnaur):

 Inspired by a successful build
 (http://darcs.haskell.org/ghcBuilder/builders/tn23/8/8.html)
 {{{
 "inplace/bin/ghc-stage2"   -H32m -O    -package-name dph-par-0.4.0 -hide-
 all-packages -i -ilibraries/dph/dph-par/../dph-common -ilibraries/dph/dph-
 par/dist-install/build -ilibraries/dph/dph-par/dist-install/build/autogen
 -Ilibraries/dph/dph-par/dist-install/build -Ilibraries/dph/dph-par/dist-
 install/build/autogen -Ilibraries/dph/dph-par/.    -optP-include
 -optPlibraries/dph/dph-par/dist-install/build/autogen/cabal_macros.h
 -package array-0.3.0.0 -package base-4.2.0.0 -package dph-base-0.4.0
 -package dph-prim-par-0.4.0 -package ghc-6.13.20100423 -package ghc-
 prim-0.2.0.0 -package random-1.0.0.2 -package template-haskell-2.4.0.0
 -Odph -funbox-strict-fields -haddock -fcpr-off -fdph-this -package-name
 dph-par -XTypeFamilies -XGADTs -XRankNTypes -XBangPatterns -XMagicHash
 -XUnboxedTuples -XTypeOperators -O2 -XGenerics -fno-warn-deprecated-flags
 -Wwarn     -odir libraries/dph/dph-par/dist-install/build -hidir
(Continue reading)

GHC | 1 May 13:35 2010

Re: #4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while relocating object file

#4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while
relocating object file
-------------------------+--------------------------------------------------
    Reporter:  igloo     |        Owner:                     
        Type:  bug       |       Status:  new                
    Priority:  highest   |    Milestone:  6.14.1             
   Component:  Compiler  |      Version:  6.13               
    Keywords:            |   Difficulty:                     
          Os:  MacOS X   |     Testcase:                     
Architecture:  x86       |      Failure:  Building GHC failed
-------------------------+--------------------------------------------------

Comment(by chak):

 Another reason to get rid of the RTS linker in favour of dyld.

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4013#comment:3>
GHC | 1 May 15:02 2010

Re: #3935: buggy libffi

#3935: buggy libffi
---------------------------------+------------------------------------------
    Reporter:  guest             |        Owner:  igloo              
        Type:  bug               |       Status:  new                
    Priority:  high              |    Milestone:  6.14.1             
   Component:  Compiler          |      Version:  6.13               
    Keywords:                    |   Difficulty:                     
          Os:  Unknown/Multiple  |     Testcase:                     
Architecture:  Unknown/Multiple  |      Failure:  Building GHC failed
---------------------------------+------------------------------------------
Changes (by igloo):

  * owner:  => igloo

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3935#comment:4>
GHC | 1 May 16:05 2010

Re: #3935: buggy libffi

#3935: buggy libffi
---------------------------------+------------------------------------------
    Reporter:  guest             |        Owner:  igloo              
        Type:  bug               |       Status:  new                
    Priority:  high              |    Milestone:  6.14.1             
   Component:  Compiler          |      Version:  6.13               
    Keywords:                    |   Difficulty:                     
          Os:  Unknown/Multiple  |     Testcase:                     
Architecture:  Unknown/Multiple  |      Failure:  Building GHC failed
---------------------------------+------------------------------------------

Comment(by igloo):

 Hmm, I'm struggling with autotools etc.
 {{{
 depbase=`echo src/debug.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
         /bin/sh ./libtool --tag=CC   --mode=compile /usr/bin/gcc
 -DHAVE_CONFIG_H -I.  -I. -I./include -Iinclude -I./src  -Wall -g
 -fexceptions -Wall -Werror  -w -MT src/debug.lo -MD -MP -MF $depbase.Tpo
 -c -o src/debug.lo src/debug.c &&\
         mv -f $depbase.Tpo $depbase.Plo
 libtool: Version mismatch error.  This is libtool 2.2.6b Debian-2.2.6b-2,
 but the
 libtool: definition of this LT_INIT comes from libtool 2.2.6.
 libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6b
 Debian-2.2.6b-2
 libtool: and run autoconf again.
 make[4]: *** [src/debug.lo] Error 63
 make[4]: Leaving directory `/home/ian/ghc/darcs/ghc/libffi/build'
 }}}
(Continue reading)

GHC | 1 May 17:15 2010

#4035: Asynchronous exception wormholes kill modularity

#4035: Asynchronous exception wormholes kill modularity
---------------------------------+------------------------------------------
    Reporter:  basvandijk        |       Owner:                
        Type:  proposal          |      Status:  new           
    Priority:  normal            |   Component:  libraries/base
     Version:  6.12.2            |    Keywords:                
          Os:  Unknown/Multiple  |    Testcase:                
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown  
---------------------------------+------------------------------------------
 Functions like `finally` create, what I call, an asynchronous exception
 wormhole because they unblock asynchronous exceptions even if you call
 them in a blocked scope:

 {{{
 finally :: IO a -> IO b -> IO a
 a `finally` sequel = block $ do
   r <- unblock a `onException` sequel
   _ <- sequel
   return r
 }}}

 This hurts modularity.

 I [http://www.haskell.org/pipermail/libraries/2010-March/013310.html
 proposed] solving this as follows:

 {{{
 finally :: IO a -> IO b -> IO a
 a `finally` sequel = do
   b <- blocked
(Continue reading)

GHC | 1 May 17:19 2010

Re: #3913: array 0.3.0.0 should depend on base >= 4.2.0.0

#3913: array 0.3.0.0 should depend on base >= 4.2.0.0
----------------------------------+-----------------------------------------
    Reporter:  cobb               |        Owner:  igloo       
        Type:  bug                |       Status:  merge       
    Priority:  normal             |    Milestone:  6.12.3      
   Component:  libraries (other)  |      Version:              
    Keywords:  wrong dependency   |   Difficulty:              
          Os:  Unknown/Multiple   |     Testcase:              
Architecture:  Unknown/Multiple   |      Failure:  None/Unknown
----------------------------------+-----------------------------------------
Changes (by igloo):

  * status:  new => merge

Comment:

 {{{
 Wed Apr 28 14:14:14 PDT 2010  Ian Lynagh <igloo <at> earth.li>
   * Tighten the base dep; fixes trac #3913
 }}}

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3913#comment:2>
GHC | 1 May 20:04 2010

Re: #3016: Long compile times, large memory use with static data in 6.10

#3016: Long compile times, large memory use with static data in 6.10
---------------------------------------------+------------------------------
  Reporter:  dons                            |          Owner:  igloo           
      Type:  bug                             |         Status:  closed          
  Priority:  normal                          |      Milestone:  6.12.3          
 Component:  Compiler                        |        Version:  6.10.1          
Resolution:  fixed                           |       Keywords:  static data     
Difficulty:  Unknown                         |             Os:  Unknown/Multiple
  Testcase:  simplCore/should_compile/T3016  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown                    |  
---------------------------------------------+------------------------------
Changes (by igloo):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 In HEAD this finishes in 1G of RAM in 2.5mins.

 6.12.2 ran out of memory on the 24th file, but rerunning the command
 succeeded, in a total of about 3mins.

 Memory use is still high, but memory use of `--make` is known to be high.

 I therefore think this is fixed.

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3016#comment:17>
(Continue reading)

GHC | 1 May 21:09 2010

Re: #2281: properFraction implemented with modf primitive?

#2281: properFraction implemented with modf primitive?
---------------------------------+------------------------------------------
    Reporter:  guest             |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  6.14.1      
   Component:  libraries/base    |      Version:  6.8.2       
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
Changes (by igloo):

  * owner:  igloo =>
  * milestone:  6.12.3 => 6.14.1

Comment:

 I've confirmed performance is worse with this program:
 {{{
 {-# LANGUAGE ForeignFunctionInterface #-}

 import Foreign
 import Foreign.C

 main :: IO ()
 main = f

 count :: Int
 count = 100000000

(Continue reading)

GHC | 2 May 00:11 2010

Re: #4035: Asynchronous exception wormholes kill modularity

#4035: Asynchronous exception wormholes kill modularity
---------------------------------+------------------------------------------
    Reporter:  basvandijk        |       Owner:                
        Type:  proposal          |      Status:  new           
    Priority:  normal            |   Component:  libraries/base
     Version:  6.12.2            |    Keywords:                
          Os:  Unknown/Multiple  |    Testcase:                
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown  
---------------------------------+------------------------------------------
Changes (by diatchki):

 * cc: iavor.diatchki <at> … (added)

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4035#comment:1>
GHC | 2 May 02:51 2010

#4036: Compiled FFI static imports are invalid when imported in GHCI

#4036: Compiled FFI static imports are invalid when imported in GHCI
-------------------------------+--------------------------------------------
    Reporter:  jmillikin       |       Owner:                             
        Type:  bug             |      Status:  new                        
    Priority:  normal          |   Component:  Compiler (FFI)             
     Version:  6.12.1          |    Keywords:                             
          Os:  Linux           |    Testcase:                             
Architecture:  x86_64 (amd64)  |     Failure:  Incorrect result at runtime
-------------------------------+--------------------------------------------
 When I try to use the FFI syntax for static storage, only modules running
 in interpreted mode (ie GHCI) work properly. Compiled modules have invalid
 pointers, and do not work. I asked in #haskell, and tommd suggested that
 this might be an architecture-dependent error in GHC.

 Here's the code used to reproduce the problem. I'm using {{{sys_siglist}}}
 declared in {{{<signal.h>}}}, since it's similar to how I originally found
 the problem, but I suspect this will occur for any static data.

 Given the following modules:

 {{{
 -- A.hs
 {-# LANGUAGE ForeignFunctionInterface #-}
 module A where
 import Foreign
 import Foreign.C

 foreign import ccall "&sys_siglist"
     siglist_a :: Ptr CString
 }}}
(Continue reading)


Gmane