Hi, The garbage collector doesn't appear to work on OS X due to a linking error. For a trivial "hello world" program I get the following output from JHC: """ $ jhc -fjgc Example.hs jhc -fjgc Example.hs jhc 0.7.4 (tokfekyuvi-27) Finding Dependencies... Using Ho Cache: '/Users/mbolingbroke/.jhc/cache' Main [Example.hs] <~/.jhc/cache/39891df74647a2bf36dd845a4c48ee8a.ho> Fresh: <~/.jhc/cache/39891df74647a2bf36dd845a4c48ee8a.ho> Typechecking... Compiling... Collected Compilation... -- typeAnalyzeMethods -- BoxifyProgram -- Boxy WorkWrap -- LambdaLift E ├─case: 27 ├─case-alt: 33 ├─lambda: 16 ├─let-binding: 19 ├─lit: 66 ├─other: 29 ├─prim: 14 └─var-use: 82 Converting to Grin... Found 0 CAFs to convert to constants, 0 of which are recursive. Recursive Constant CAFS Writing "hs.out_code.c" Running: gcc '-std=gnu99' -D_GNU_SOURCE '-falign-functions=4' -ffast-math -Wextra -Wall -Wno-unused-parameter -o hs.out hs.out_code.c -DNDEBUG -O3 '-D_JHC_GC=_JHC_GC_JGC' hs.out_code.c:220:1: warning: "ALIGN" redefined In file included from /usr/include/machine/param.h:37, from /usr/include/sys/param.h:110, from hs.out_code.c:143: /usr/include/i386/param.h:83:1: warning: this is the location of the previous definition hs.out_code.c: In function ‘gc_check_heap’: hs.out_code.c:1606: warning: comparison of distinct pointer types lacks a cast hs.out_code.c:1606: warning: comparison of distinct pointer types lacks a cast hs.out_code.c: At top level: hs.out_code.c:1642: warning: ‘gc_add_root’ defined but not used Undefined symbols: "__end", referenced from: _gc_alloc in ccFhQDIs.o _gc_alloc in ccFhQDIs.o _gc_alloc in ccFhQDIs.o "__start", referenced from: _gc_alloc in ccFhQDIs.o _gc_alloc in ccFhQDIs.o _gc_alloc in ccFhQDIs.o ld: symbol(s) not found collect2: ld returned 1 exit status jhc: user error (C code did not compile.) """ Cheers, Max
Hi, I know there is an issue on some vesions of OSX due to the lack of posix_memalign, but this appears to be a different thing. Can you send me the output of 'uname -a' and 'gcc --version' and what version of OSX you are using? thanks. I use the _start and _end symbols to determine if a memory address is within the range of predefined constants or not. I think I will have to come up with a better mechanism that can also determine if an address in on the stack as well... John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
On 11 July 2010 22:35, John Meacham
Hi, I know there is an issue on some vesions of OSX due to the lack of posix_memalign, but this appears to be a different thing.
Yep, I'm on 10.6 which apparently has memalign.
Can you send me the output of 'uname -a' and 'gcc --version' and what version of OSX you are using? thanks.
Same as in my reply on -cafe: OS X 10.6.4 and: $ uname -a && gcc --version Darwin REDACTED.ac.uk 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Thanks, Max
On Sun, Jul 11, 2010 at 11:10:29PM +0100, Max Bolingbroke wrote:
On 11 July 2010 22:35, John Meacham
wrote: Hi, I know there is an issue on some vesions of OSX due to the lack of posix_memalign, but this appears to be a different thing.
Yep, I'm on 10.6 which apparently has memalign.
Can you send me the output of 'uname -a' and 'gcc --version' and what version of OSX you are using? thanks.
Same as in my reply on -cafe: OS X 10.6.4 and:
$ uname -a && gcc --version Darwin REDACTED.ac.uk 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Hi, out of curiousity, could you try editing the .c file and adding #define _start start #define _end end after the header file includes and before the extern void _start,_end; declarations then try recompiling it? then if that doesn't work, try #define _start __start #define _end __end The command you need to run to recompile the .c file will be embedded in the file near the top of it, or the utils/recomp.prl script will pull it out and recompile a .c generated by jhc. (useful when debugging the rts). I know that OSX uses different rules for linking and whether underscores are prepended, but I forget the details. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
Hi John,
#define _start start #define _end end
Neither of these suggestions changes the link error. Are you expecting the _start and _end labels to be defined in the .s file output by GCC? I can't see anything like them in the -S output. If not, what library do they originate from? Is there any other information you might be able to use to figure out this bug? Cheers, Max
On Sun, Jul 11, 2010 at 11:56:01PM +0100, Max Bolingbroke wrote:
Are you expecting the _start and _end labels to be defined in the .s file output by GCC? I can't see anything like them in the -S output. If not, what library do they originate from?
Neither, they are generated by the linker on linux, I guess they just don't exist on OSX.
Is there any other information you might be able to use to figure out this bug?
No, I was just hoping one of those might be an easy fix. The _start,_end mechanism is pretty much a hack anyway, I was going to replace it with a more reliable mechanism in any case. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
participants (2)
-
John Meacham -
Max Bolingbroke