[racket] Bulding for Solaris 5.10 AMD64

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Tue Jul 20 21:20:34 EDT 2010

I've pushed a repair to the git repo, along with your patch to
"sconfig.h".

The bug was in the code that patches a return address in the stack to
release cached stack-trace information. The JIT-generated code at the
patched-in address wasn't saving and restoring the return value
correctly. The only remaining mystery is why this bug hasn't caused
lots of trouble before.

At Mon, 19 Jul 2010 15:36:59 +0100, Tim Brown wrote:
> Matt,
> 
> On 17/07/10 16:14, Matthew Flatt wrote:
> > Your "sconfig.h" changes look right. My only wild guess at the moment
> > is that something else is relying on the C preprocessor setting
> > __x86_64__, as opposed to __x86_64. If you add
> >
> >   #define __x86_64__ 1
> 
> I've added this in amongst the other definitions in my changes to
> `sconfig.h'.
> 
> > does that help?
> 
> I'm afraid not.
> 
> During the build (with no switching off of the JIT) I still get:
> 
> ...
> gmake[4]: Entering directory 
> `/usr2/other/plt-5.0/src/SunOS-5.10-amd64/racket/gc2'
> env XFORM_PRECOMP=yes ../racketcgc -cqu ../../../racket/gc2/xform.rkt 
> --setup . --cpp "gcc -m64 -E -I./.. -I../../../racket/gc2/../include 
> -DNEWGC_BTC_ACCOUNT  -DMZ_NO_ICONV -D_LARGEFILE_SOURCE 
> -D_FILE_OFFSET_BITS=64 "  --keep-lines -o xsrc/precomp.h 
> ../../../racket/gc2/precomp.c
> module name resolver: expected result of type <resolved-module-path>; given 
> #<variable-code>
> ...
> gmake: *** [all] Error 2
> 
> I am left with that `racketgcg' in my build directory. It has been built
> with the JIT non (more precisely, without me making any effort to switch
> JIT off).
> 
> When I run it on the command line, I get:
> 
>  > ./racket/racketcgc
> Welcome to Racket v5.0 [cgc].
> module name resolver: expected result of type <resolved-module-path>; given 
> #<bad-value>
> module name resolver: expected result of type <resolved-module-path>; given 
> #<bad-value>
> 
> The error is printed twice on my terminal - for 1 error or 2, I'm not sure.
> 
> If I run:
> 
>  > ./racket/racketcgc --no-jit
> Welcome to Racket v5.0 [cgc].
>  > (exit)
> 
> It all passes off quite smoothly.
> 
> > Something has definitely gone wrong inside `racketcgc', though. I
> > imagine that if you set the environment variable PLTNOMZJIT, then 3m
> > `racket' will build, but running the resulting `racket' without
> > PLTNOMZJIT will produce the same error.
> 
>  From what you've written, this behaviour seems to be what you would
> expect.
> 
> Is there anything I can do to intercept `racketcgc' before it calls
> whatever it calls to throw this error?
> 
> Regards,
> 
> Tim
> 
> -- 
> Tim Brown <tim.brown at cityc.co.uk>  | City Computing Limited            |
> T: +44 20 8770 2110                | City House, Sutton Park Road      |
> F: +44 20 8770 2130                | Sutton, Surrey, SM1 2AE, GB       |
> -----------------------------------------------------------------------|
> BEAUTY:  What's in your eye when you have a bee in your hand           |
> -----------------------------------------------------------------------'
> City Computing Limited registered in London No. 1767817.
> Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
> VAT number 372 8290 34.


Posted on the users mailing list.