Re: Build failures on Mac OS X 10.5
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 make the stage1 compiler by putting also a line GhcStage1HcOpts = -O0 -DDEBUG into mk/build.mk (as suggested on http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking) Cheers Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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 PATH=~/bin:$PATH C. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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 a surprise). The messages about .dSYM are due to a change in the default debugging file format for 10.5. I can't say any more than that. Is there anything else you would like me to try? Do you have another gcc (like gcc-3.3) that you can try out? Would it help to switch on debugging flags (how and which?) for gcc to find out the cause of the crash? Cheers Christian m29:~ maeder$ ll /usr/bin/gcc-3.3 -r-xr-xr-x 1 root wheel 260616 Sep 12 2006 /usr/bin/gcc-3.3 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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 on 10.5. So this is definitely something about 10.5 (not a surprise). The messages about .dSYM are due to a change in the default debugging file format for 10.5. I can't say any more than that. Is there anything else you would like me to try? Do you have another gcc (like gcc-3.3) that you can try out? 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? Would it help to switch on debugging flags (how and which?) for gcc to find out the cause of the crash? I'll try this next. Thanks, Deborah ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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, since we have the same one, too. Cheers Christian P.S. In your configure log are spurious messages: rm: conftest.dSYM: is a directory that I don't have (attached) log.conf.bz2 Description: application/bzip ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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 messages about .dSYM are due to a change in the default debugging file format for 10.5. I can't say any more than that. Is there anything else you would like me to try? Thanks, Deborah On May 25, 2007, at 1:48 AM, Christian Maeder wrote: 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, since we have the same one, too. Cheers Christian P.S. In your configure log are spurious messages: rm: conftest.dSYM: is a directory that I don't have (attached) log.conf.bz2 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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 binary distribution you don't need to compile the sources anymore (except for the sake of testing). This is purely for the sake of testing. As the subject indicates, I'm trying to build GHC from source on 10.5. I've built earlier versions successfully on 10.4. I did do a make clean between attempts, but I will try throwing the source directory away and re-extracting from the tar archive next. 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 = -O -fasm GhcStage2HcOpts = -O -fasm GhcLibHcOpts= -O -fasm to your mk/build.mk. This might fix your build, but you'll still be left with some incompatibility between GHC and the gcc in 10.5. You already encountered one such problem, when using -split-objs, right? If you get a successful build it should be easier to debug this. I already have a usable build -- the 6.6.1 binary release that Christian put together works fine on 10.5. Actually there appears to be a problem with that 6.6.1 binary release, at least on your system. Both crashes that you described were in the stage1 compiler, which is compiled by your installed 6.6.1. So either (a) your installed 6.6.1 is generating bogus code (which is why I suspected a gcc incompatibility, because that would explain why Christian doesn't see the same crash) (b) there's a bug in GHC which makes it segfault on OS X 10.5. I'd say (b) is highly unlikely - GHC just a Haskell program (well, mostly), and it therefore shouldn't segfault. Still, you tried with -O -fasm and that didn't help. So I'm at a loss to explain why your stage1 GHC is crashing. Probably the only way forward at this point is to get out gdb and figure out what's going wrong. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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 ghc-6.6.1/lib/i386-apple-darwin/ghc-6.6.1 ghc-6.6.1/lib/i386-apple-darwin/ghc-6.6.1: GNUreadline.framework/Versions/A/GNUreadline (compatibility version 5.0.0, current version 5.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.7) GMP.framework/Versions/A/GMP (compatibility version 7.0.0, current version 7.0.0) versus GMP (v8) on our download page: $ otool -L ~/Library/Frameworks/GMP.framework/Versions/A/GMP /home/maeder/Library/Frameworks/GMP.framework/Versions/A/GMP: GMP.framework/Versions/A/GMP (compatibility version 8.0.0, current version 8.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.7) but. I've no problem with either GMP frameworks C. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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 don't need to compile the sources anymore (except for the sake of testing). This is purely for the sake of testing. As the subject indicates, I'm trying to build GHC from source on 10.5. I've built earlier versions successfully on 10.4. I did do a make clean between attempts, but I will try throwing the source directory away and re-extracting from the tar archive next. 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 = -O -fasm GhcStage2HcOpts = -O -fasm GhcLibHcOpts= -O -fasm to your mk/build.mk. This might fix your build, but you'll still be left with some incompatibility between GHC and the gcc in 10.5. You already encountered one such problem, when using -split-objs, right? If you get a successful build it should be easier to debug this. I already have a usable build -- the 6.6.1 binary release that Christian put together works fine on 10.5. My only goal here is to figure out why GHC doesn't build on 10.5, so that either 10.5 or GHC (depending) can get fixed. The prior problem was not with gcc but rather with the system headers. I'm not aware of any problem between GHC and the gcc in 10.5 at the moment. I will try the build.mk options you suggest and report back. Thanks, Deborah ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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 = -O -fasm GhcStage2HcOpts = -O -fasm GhcLibHcOpts= -O -fasm to your mk/build.mk. This might fix your build, but you'll still be left with some incompatibility between GHC and the gcc in 10.5. You already encountered one such problem, when using -split-objs, right? If you get a successful build it should be easier to debug this. I tried this and it crashed in exactly the same way in the same place. Thanks, Deborah ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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: 2007-05-18 13:09:38.973 -0700 OS Version: Mac OS X 10.5 (9A441) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: 0x000d, 0x Crashed Thread: 0 Thread 0 Crashed: 0 ghc-6.6.1 0x007437b7 sbuE_info + 15 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x007437a8 ebx: 0x008ca008 ecx: 0x011b71bc edx: 0xc002 edi: 0x011df1b8 esi: 0x011df1b0 ebp: 0x02053c78 esp: 0xbfffcf10 ss: 0x001f efl: 0x00010206 eip: 0x007437b7 cs: 0x0017 ds: 0x001f es: 0x001f fs: 0x gs: 0x0037 cr2: 0x004a6d18 Binary Images: 0x1000 - 0x82dff7 +ghc-6.6.1 ??? (???) d12a8b5830ee3fbc0948df855328fad8 /Volumes/Totoro/source/ghc-6.6.1/ compiler/stage1/ghc -6.6.1 0xe4d000 - 0xe92fff +GMP ??? (???) /Library/Frameworks/ GMP.framework/Versions/A/GMP 0x8fe0 - 0x8fe2c008 dyld 84.0 (???) eb2d7669f9ba168508e541219dc55fae /usr/lib/dyld 0x91b63000 - 0x91ca8fe0 libSystem.B.dylib ??? (???) 43e841444da46670e61de0dc8bd7a2ff /usr/lib/libSystem.B.dylib 0x92df4000 - 0x92df6fe7 libmathCommon.A.dylib ??? (???) /usr/lib/ system/libmathCommon.A.dylib 0x94e6e000 - 0x94e75fed libgcc_s.1.dylib ??? (???) 1b0a4147d838c7cdc644818e0d15ec25 /usr/lib/libgcc_s.1.dylib 0x - 0x1780 libSystem.B.dylib ??? (???) /usr/lib/ libSystem.B.dylib Any suggestions for how to proceed at this point? Thanks, Deborah On May 17, 2007, at 8:44 PM, Deborah Goldsmith wrote: 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 -istage2/types -istage2/hsSyn -istage2/prelude - istage2/rename -istage2/typecheck -istage2/deSugar -istage2/ coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/ main -istage2/profiling -istage2/parser -istage2/cprAnalysis - istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/ nativeGen -istage2/ghci -Istage2 -DGHCI -DBREAKPOINT -package template-haskell -threaded -cpp -fglasgow-exts -fno-generics -Rghc- timing -I. -Iparser -package unix -package Cabal -package regex- compat -ignore-package lang -recomp -Rghc-timing -H16M '-#include cutils.h' -package-name ghc-6.6.1 -fgenerics-c ghci/ ByteCodeGen.lhs -o stage2/ghci/ByteCodeGen.o -ohi stage2/ghci/ ByteCodeGen.hi make[2]: *** [stage2/ghci/ByteCodeGen.o] Segmentation fault make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 I'll be happy to do any other investigation anyone suggests. Thanks, Deborah On May 8, 2007, at 2:29 AM, Simon Marlow wrote: 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-c Foreign/C/Error.hs -o Foreign/C/Error.o -ohi Foreign/C/Error.hi /tmp/ghc78351_0/ghc78351_0.split__108.s:unknown:Undefined local symbol L_strerror$UNIX2003$stub So the reference actually is to the version *with* $UNIX2003 appended. Also, both strerror and strerror$UNIX2003 are present in the library being linked against, so if the FFI were going straight to strerror (old version), it would find it, because it's still there for compatibility. The only way that a symbol like L_strerror$UNIX2003$stub would be generated would be if someone *were* including unistd.h. There's no way the $UNIX2003 would creep in otherwise. Also, it says it's a local symbol. Also note the leading L; I would expect the symbol to be _strerror$UNIX2003$stub. The actual symbols exported by /usr/lib/libSystem.dylib in 10.5 are: c59c T _strerror 000b7fb4 T _strerror$UNIX2003 Ok, then we'll have to dig further. Suggestions: - turn off splitting: add SplitObjs=NO to mk/build/mk. If this makes the error go away, then the problem is likely in the split script (driver/split/ghc-split.lprl). - If the error is still there without splitting, then compile the module with -keep-tmp-files, and take a look at the .s and .raw_s files to see where the local symbol is coming from. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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 -package-name base-2.1.1 - O -Rghc-timing -fgenerics -fgenerics-c GHC/Float.lhs -o GHC/ Float.o -ohi GHC/Float.hi make[2]: *** [GHC/Float.o] Segmentation fault Finished making all in base: 0 Here is the crash report: Process: ghc-6.6.1 [83545] Path:/Volumes/Totoro/source/ghc-6.6.1-build/compiler/ stage1/ghc-6.6.1 Identifier: ghc-6.6.1 Version: ??? (???) Code Type: X86 (Native) Parent Process: make [83345] Date/Time: 2007-05-18 16:21:23.334 -0700 OS Version: Mac OS X 10.5 (9A441) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: 0x000d, 0x Crashed Thread: 0 Thread 0 Crashed: 0 ghc-6.6.1 0x00750f7f sbqE_info + 15 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00750f70 ebx: 0x008da008 ecx: 0x0002 edx: 0xc002 edi: 0x02111b40 esi: 0x02111b38 ebp: 0x0264f924 esp: 0xbfffd4a0 ss: 0x001f efl: 0x00010216 eip: 0x00750f7f cs: 0x0017 ds: 0x001f es: 0x001f fs: 0x gs: 0x0037 cr2: 0x004aff64 Binary Images: 0x1000 - 0x83cff3 +ghc-6.6.1 ??? (???) d9ea7b54cd7cd3d2bc459a9035e6fe28 /Volumes/Totoro/source/ghc-6.6.1- build/compiler/stag e1/ghc-6.6.1 0xe69000 - 0xeaefff +GMP ??? (???) /Library/Frameworks/ GMP.framework/Versions/A/GMP 0x8fe0 - 0x8fe2c008 dyld 84.0 (???) eb2d7669f9ba168508e541219dc55fae /usr/lib/dyld 0x91b63000 - 0x91ca8fe0 libSystem.B.dylib ??? (???) 43e841444da46670e61de0dc8bd7a2ff /usr/lib/libSystem.B.dylib 0x92df4000 - 0x92df6fe7 libmathCommon.A.dylib ??? (???) /usr/lib/ system/libmathCommon.A.dylib 0x94e6e000 - 0x94e75fed libgcc_s.1.dylib ??? (???) 1b0a4147d838c7cdc644818e0d15ec25 /usr/lib/libgcc_s.1.dylib 0x - 0x1780 libSystem.B.dylib ??? (???) /usr/lib/ libSystem.B.dylib Deborah On May 18, 2007, at 1:59 PM, Deborah Goldsmith wrote: 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: 2007-05-18 13:09:38.973 -0700 OS Version: Mac OS X 10.5 (9A441) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: 0x000d, 0x Crashed Thread: 0 Thread 0 Crashed: 0 ghc-6.6.1 0x007437b7 sbuE_info + 15 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x007437a8 ebx: 0x008ca008 ecx: 0x011b71bc edx: 0xc002 edi: 0x011df1b8 esi: 0x011df1b0 ebp: 0x02053c78 esp: 0xbfffcf10 ss: 0x001f efl: 0x00010206 eip: 0x007437b7 cs: 0x0017 ds: 0x001f es: 0x001f fs: 0x gs: 0x0037 cr2: 0x004a6d18 Binary Images: 0x1000 - 0x82dff7 +ghc-6.6.1 ??? (???) d12a8b5830ee3fbc0948df855328fad8 /Volumes/Totoro/source/ghc-6.6.1/ compiler/stage1/ghc -6.6.1 0xe4d000 - 0xe92fff +GMP ??? (???) /Library/Frameworks/ GMP.framework/Versions/A/GMP 0x8fe0 - 0x8fe2c008 dyld 84.0 (???) eb2d7669f9ba168508e541219dc55fae /usr/lib/dyld 0x91b63000 - 0x91ca8fe0 libSystem.B.dylib ??? (???) 43e841444da46670e61de0dc8bd7a2ff /usr/lib/libSystem.B.dylib 0x92df4000 - 0x92df6fe7 libmathCommon.A.dylib ??? (???) /usr/lib/ system/libmathCommon.A.dylib 0x94e6e000 - 0x94e75fed libgcc_s.1.dylib ??? (???) 1b0a4147d838c7cdc644818e0d15ec25 /usr/lib/libgcc_s.1.dylib 0x - 0x1780 libSystem.B.dylib ??? (???) /usr/lib/ libSystem.B.dylib Any suggestions for how to proceed at this point? Thanks, Deborah On May 17, 2007, at 8:44 PM, Deborah Goldsmith wrote: 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 -istage2/types -istage2/hsSyn -istage2/prelude - istage2/rename -istage2/typecheck -istage2/deSugar -istage2/ coreSyn -istage2/specialise -istage2/simplCore -istage2/ stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen - istage2/main -istage2/profiling -istage2/parser -istage2/ cprAnalysis -istage2/ndpFlatten -istage2/iface -istage2/cmm - istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -DBREAKPOINT - package template-haskell -threaded -cpp -fglasgow-exts -fno- generics -Rghc-timing -I. -Iparser -package unix -package Cabal - package regex-compat -ignore-package lang -recomp -Rghc-timing - H16M '-#include cutils.h' -package-name
Re: Build failures on Mac OS X 10.5
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 -istage2/types -istage2/hsSyn -istage2/prelude - istage2/rename -istage2/typecheck -istage2/deSugar -istage2/ coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal - istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main - istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen - istage2/ghci -Istage2 -DGHCI -DBREAKPOINT -package template-haskell - threaded -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser - package unix -package Cabal -package regex-compat -ignore-package lang -recomp -Rghc-timing -H16M '-#include cutils.h' -package- name ghc-6.6.1 -fgenerics-c ghci/ByteCodeGen.lhs -o stage2/ ghci/ByteCodeGen.o -ohi stage2/ghci/ByteCodeGen.hi make[2]: *** [stage2/ghci/ByteCodeGen.o] Segmentation fault make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 I'll be happy to do any other investigation anyone suggests. Thanks, Deborah On May 8, 2007, at 2:29 AM, Simon Marlow wrote: 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-c Foreign/C/Error.hs -o Foreign/C/Error.o -ohi Foreign/C/Error.hi /tmp/ghc78351_0/ghc78351_0.split__108.s:unknown:Undefined local symbol L_strerror$UNIX2003$stub So the reference actually is to the version *with* $UNIX2003 appended. Also, both strerror and strerror$UNIX2003 are present in the library being linked against, so if the FFI were going straight to strerror (old version), it would find it, because it's still there for compatibility. The only way that a symbol like L_strerror$UNIX2003$stub would be generated would be if someone *were* including unistd.h. There's no way the $UNIX2003 would creep in otherwise. Also, it says it's a local symbol. Also note the leading L; I would expect the symbol to be _strerror$UNIX2003$stub. The actual symbols exported by /usr/lib/libSystem.dylib in 10.5 are: c59c T _strerror 000b7fb4 T _strerror$UNIX2003 Ok, then we'll have to dig further. Suggestions: - turn off splitting: add SplitObjs=NO to mk/build/mk. If this makes the error go away, then the problem is likely in the split script (driver/split/ghc-split.lprl). - If the error is still there without splitting, then compile the module with -keep-tmp-files, and take a look at the .s and .raw_s files to see where the local symbol is coming from. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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-c Foreign/C/Error.hs -o Foreign/C/Error.o -ohi Foreign/C/Error.hi /tmp/ghc78351_0/ghc78351_0.split__108.s:unknown:Undefined local symbol L_strerror$UNIX2003$stub So the reference actually is to the version *with* $UNIX2003 appended. Also, both strerror and strerror$UNIX2003 are present in the library being linked against, so if the FFI were going straight to strerror (old version), it would find it, because it's still there for compatibility. The only way that a symbol like L_strerror$UNIX2003$stub would be generated would be if someone *were* including unistd.h. There's no way the $UNIX2003 would creep in otherwise. Also, it says it's a local symbol. Also note the leading L; I would expect the symbol to be _strerror$UNIX2003$stub. The actual symbols exported by /usr/lib/libSystem.dylib in 10.5 are: c59c T _strerror 000b7fb4 T _strerror$UNIX2003 Ok, then we'll have to dig further. Suggestions: - turn off splitting: add SplitObjs=NO to mk/build/mk. If this makes the error go away, then the problem is likely in the split script (driver/split/ghc-split.lprl). - If the error is still there without splitting, then compile the module with -keep-tmp-files, and take a look at the .s and .raw_s files to see where the local symbol is coming from. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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 __DARWIN_UNIX03 pid_tsetpgrp(void) __DARWIN_ALIAS(setpgrp); #else /* !__DARWIN_UNIX03 */ int setpgrp(pid_t pid, pid_t pgrp);/* obsoleted by setpgid() */ #endif /* __DARWIN_UNIX03 */ where __DARWIN_ALIAS and __DARWIN_UNIX03 come from /usr/include/sys/cdefs.h: #if __DARWIN_UNIX03 !defined(__LP64__) #define __DARWIN_ALIAS(sym) __asm(_ __STRING(sym) $UNIX2003) #else #define __DARWIN_ALIAS(sym) #endif The idea behind this is that if something is compiled with __DARWIN_UNIX03 (for Unix 2003 conformance) it links to a version of the routine with $UNIX2003 appended (for 32-bit architectures). If not, it gets the old version (for compatibility). In 10.5, strerror() now falls under this switch where it didn't in 10.4: char*strerror(int) __DARWIN_ALIAS(strerror); (In this case the function signature hasn't changed as it did with setpgrp, but presumably the semantics have.) I don't have a MacOS X machine here to investigate, but I can take a guess at what the problem is. When GHC compiles using its built-in native code generator, the names of functions mentioned in FFI declarations are taken literally: nothing is reading /usr/include/unistd.h, so there's no way to make the connection between strerror and strerror$UNIX2003. To justify this, we say that the Haskell FFI is binding to the C ABI, not API. The way to work around it is to add a stub C function to one of the C files in the base package, e.g. HsBase.h. There are many such stubs there already, for C functions that are implemented as macros. In most cases the C standard says which functions are allowed to be implemented as macros, so we can use appropriate stubs to forestall such issues, but changing the name with __asm doesn't count as a macro (presumably that's why you guys did it this way?). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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 from /usr/include/unistd.h on 10.4.9: #if __DARWIN_UNIX03 pid_tsetpgrp(void) __DARWIN_ALIAS(setpgrp); #else /* !__DARWIN_UNIX03 */ int setpgrp(pid_t pid, pid_t pgrp);/* obsoleted by setpgid() */ #endif /* __DARWIN_UNIX03 */ where __DARWIN_ALIAS and __DARWIN_UNIX03 come from /usr/include/ sys/cdefs.h: #if __DARWIN_UNIX03 !defined(__LP64__) #define __DARWIN_ALIAS(sym) __asm(_ __STRING(sym) $UNIX2003) #else #define __DARWIN_ALIAS(sym) #endif The idea behind this is that if something is compiled with __DARWIN_UNIX03 (for Unix 2003 conformance) it links to a version of the routine with $UNIX2003 appended (for 32-bit architectures). If not, it gets the old version (for compatibility). In 10.5, strerror() now falls under this switch where it didn't in 10.4: char*strerror(int) __DARWIN_ALIAS(strerror); (In this case the function signature hasn't changed as it did with setpgrp, but presumably the semantics have.) I don't have a MacOS X machine here to investigate, but I can take a guess at what the problem is. When GHC compiles using its built- in native code generator, the names of functions mentioned in FFI declarations are taken literally: nothing is reading /usr/include/ unistd.h, so there's no way to make the connection between strerror and strerror$UNIX2003. To justify this, we say that the Haskell FFI is binding to the C ABI, not API. The way to work around it is to add a stub C function to one of the C files in the base package, e.g. HsBase.h. There are many such stubs there already, for C functions that are implemented as macros. In most cases the C standard says which functions are allowed to be implemented as macros, so we can use appropriate stubs to forestall such issues, but changing the name with __asm doesn't count as a macro (presumably that's why you guys did it this way?). Thanks for replying! 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-c Foreign/C/Error.hs -o Foreign/C/Error.o -ohi Foreign/C/Error.hi /tmp/ghc78351_0/ghc78351_0.split__108.s:unknown:Undefined local symbol L_strerror$UNIX2003$stub So the reference actually is to the version *with* $UNIX2003 appended. Also, both strerror and strerror$UNIX2003 are present in the library being linked against, so if the FFI were going straight to strerror (old version), it would find it, because it's still there for compatibility. The only way that a symbol like L_strerror$UNIX2003$stub would be generated would be if someone *were* including unistd.h. There's no way the $UNIX2003 would creep in otherwise. Also, it says it's a local symbol. Also note the leading L; I would expect the symbol to be _strerror$UNIX2003$stub. The actual symbols exported by /usr/lib/ libSystem.dylib in 10.5 are: c59c T _strerror 000b7fb4 T _strerror$UNIX2003 Thanks again, Deborah ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Build failures on Mac OS X 10.5
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 pid_tsetpgrp(void) __DARWIN_ALIAS(setpgrp); #else /* !__DARWIN_UNIX03 */ int setpgrp(pid_t pid, pid_t pgrp);/* obsoleted by setpgid() */ #endif /* __DARWIN_UNIX03 */ where __DARWIN_ALIAS and __DARWIN_UNIX03 come from /usr/include/sys/ cdefs.h: #if __DARWIN_UNIX03 !defined(__LP64__) #define __DARWIN_ALIAS(sym) __asm(_ __STRING(sym) $UNIX2003) #else #define __DARWIN_ALIAS(sym) #endif The idea behind this is that if something is compiled with __DARWIN_UNIX03 (for Unix 2003 conformance) it links to a version of the routine with $UNIX2003 appended (for 32-bit architectures). If not, it gets the old version (for compatibility). In 10.5, strerror() now falls under this switch where it didn't in 10.4: char*strerror(int) __DARWIN_ALIAS(strerror); (In this case the function signature hasn't changed as it did with setpgrp, but presumably the semantics have.) I tried configuring GHC with: ./configure CFLAGS=-O2 -D__DARWIN_UNIX03=0 but it didn't fix the problem for me. Thanks for making contact. Can you tell us any more about why Apple is starting to find Haskell of sufficient interest to try to solve these issues? No great mystery. I can't say whether Apple is interested in Haskell, but I am, and I've been learning it in my not-so-copious free time. I ran into this when trying to build GHC on 10.5. We try to let open- source developers know if there are problems in their projects on a new version of Mac OS X, because we like the projects to work when the new version comes out. :-) If you can think of something to try I'll be happy to try it for you and report back. Thanks, Deborah On May 4, 2007, at 5:43 AM, Malcolm Wallace wrote: Deborah Goldsmith [EMAIL PROTECTED] wrote: /tmp/ghc78351_0/ghc78351_0.split__108.s:unknown: Undefined local symbol L_strerror$UNIX2003$stub The standard unix symbol 'strerror' is imported by the base package from module Foreign/C/Error.hs like this: foreign import ccall unsafe string.h strerror :: Errno - IO (Ptr CChar) The corresponding prototype for 'strerror' in /usr/include/string.h on MacOS 10.4.9 is: char *strerror(int); Which all looks like it matces up OK. I presume that in MacOS 10.5, something in this area has changed to do with localisation, or internationalisation. Perhaps 'strerror' is no longer implemented as a function, but as a cpp macro. Perhaps 'strerror' is no longer physically located in libc.dylib. Perhaps there are now conditional sections around 'strerror' which mean that we need to set a pre-processing symbol to select the appropriate version of the prototype. Can you give us any snippets from the Leopard version of /usr/include/string.h that might confirm one of these hypotheses? I can't divulge any confidential information about Leopard but I did get an OK to work with you folks to try to isolate the cause of this problem. If it's on our side we'd like to fix it, and if it's on your side we'd like to help you be ready for Leopard. Thanks for making contact. Can you tell us any more about why Apple is starting to find Haskell of sufficient interest to try to solve these issues? Regards, Malcolm ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
