Hi,
I've created a ticket on this matter:
http://hackage.haskell.org/trac/ghc/ticket/1437
(Add further comments as you think fit)
Deborah Goldsmith schrieb:
2. Move in mk/build.mk to work around splitter incompatibility with Leopard
Does mk/build.mk only contain SplitObjs = NO?
I suggest to
Deborah Goldsmith schrieb:
I kind of doubt this is the problem, but I could try it. I assume I can
fiddle with the configuration variables and have it use gcc-3.3 instead
of gcc?
I usually make a link to another gcc and let it find first in the path.
ln -s /usr/bin/gcc-3.3 ~/bin
export
Deborah Goldsmith schrieb:
OK, I was able to build 6.6.1 successfully on 10.4 (Intel Core Duo) with
both the standard configuration and with SplitObjs = NO. The build was
done with the same binary 6.6.1 release, GMP, and GNU readline as on
10.5. So this is definitely something about 10.5 (not
On May 30, 2007, at 2:24 AM, Christian Maeder wrote:
Deborah Goldsmith schrieb:
OK, I was able to build 6.6.1 successfully on 10.4 (Intel Core
Duo) with
both the standard configuration and with SplitObjs = NO. The build
was
done with the same binary 6.6.1 release, GMP, and GNU readline as
Deborah Goldsmith schrieb:
I'm also going to try building on 10.4.x to see if this is 10.5-specific.
Yes, do so.
One more variable is that the build on 10.5 was done on a machine with
an Intel Core 2 Duo processor. I don't know if that's relevant.
No idea, the GMP framework should be ok,
OK, I was able to build 6.6.1 successfully on 10.4 (Intel Core Duo)
with both the standard configuration and with SplitObjs = NO. The
build was done with the same binary 6.6.1 release, GMP, and GNU
readline as on 10.5. So this is definitely something about 10.5 (not
a surprise).
The
Deborah Goldsmith wrote:
On May 23, 2007, at 2:08 AM, Simon Marlow wrote:
Deborah Goldsmith wrote:
On May 22, 2007, at 1:59 AM, Christian Maeder wrote:
What are you trying to achieve? Did you compile parts with ghc-6.6 and
ghc-6.6.1? (That may explain the crash.)
If you have installed my
Christian Maeder schrieb:
I can only offer to make a rebuild with any options that might help. May
it be a problem with the GMP framework? The one for downloading
(gmp-4.2.1) might be different from the one that's globally installed
here (gmp-4.2).
GMP (v7) used by ghc
$ otool -L
On May 23, 2007, at 2:08 AM, Simon Marlow wrote:
Deborah Goldsmith wrote:
On May 22, 2007, at 1:59 AM, Christian Maeder wrote:
What are you trying to achieve? Did you compile parts with
ghc-6.6 and
ghc-6.6.1? (That may explain the crash.)
If you have installed my binary distribution you
On May 23, 2007, at 2:08 AM, Simon Marlow wrote:
One possibility is that if you compiled GHC via C (I believe this
is still the default in 6.6.1), then changes in the gcc shipped
with 10.5 might be causing problems. You might get further by adding
SRC_HC_OPTS = -O -fasm
GhcStage1HcOpts
Here is more detailed crash information, FWIW:
Process: ghc-6.6.1 [37476]
Path:/Volumes/Totoro/source/ghc-6.6.1/compiler/stage1/
ghc-6.6.1
Identifier: ghc-6.6.1
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: make [37340]
Date/Time:
I replaced the binary 6.6 distribution I was using with the 6.6.1 Mac
OS X Intel binary distribution from Christian Maeder, then tried
again. It now crashes in a different place:
../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude
-#include HsBase.h -funbox-strict-fields
OK, setting SplitObjs = NO got it past that compilation error, so it
must be the splitter script as you suggest. Unfortunately, there was
a subsequent error: the stage1 compiler crashed building stage 2:
../compiler/stage1/ghc-inplace -H16m -O -istage2/utils -istage2/
basicTypes
Deborah Goldsmith wrote:
Actually, I'm not sure that's what's going on. The unresolved symbol
error is:
../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude
-#include HsBase.h -funbox-strict-fields -package-name base-2.1.1
-O -Rghc-timing -fgenerics -fgenerics -split-objs
Deborah Goldsmith wrote:
I believe what's going on here is that strerror has been changed for
better Unix conformance, under the control of the __DARWIN_UNIX03
preprocessor flag. This is something you'll see in 10.4.x too. Here's an
excerpt from /usr/include/unistd.h on 10.4.9:
#if
On May 7, 2007, at 6:04 AM, Simon Marlow wrote:
Deborah Goldsmith wrote:
I believe what's going on here is that strerror has been changed
for better Unix conformance, under the control of the
__DARWIN_UNIX03 preprocessor flag. This is something you'll see in
10.4.x too. Here's an excerpt
Hi Malcolm,
I believe what's going on here is that strerror has been changed for
better Unix conformance, under the control of the __DARWIN_UNIX03
preprocessor flag. This is something you'll see in 10.4.x too. Here's
an excerpt from /usr/include/unistd.h on 10.4.9:
#if __DARWIN_UNIX03
17 matches
Mail list logo
