Re: [Gcl-devel] Re: Patch for gcl-2.6.7 on MacOSX(10.4.2) to build maxima-5.9.[12] and so on.

[Camm Maguire]

Greetings!

Aurelien Chanudet <address@hidden> writes:

> > 1) revert void *my_sbrk to char *my_sbrk.  Can we use a name which
> >    does not conflict with any system routine?
> 
> I suspect this is becausse /usr/include/unistd.h has changed between
> Mac OS X 10.2 (which I think you have at utexas) and 10.4 which I
> have. I'd suggest something like :
> 
> #if defined(flag identifyin Mac OS X 10.4)
> void *my_sbrk();
> #else
> char *my_sbrk();
> #endif
> 
> If you're happy with that, I can commit something like that.
> 

This would be great, please, if possible on both branch
Version_2_6_8pre and HEAD.

> > 2) Add _setjmp(env) to plttest.c to get both _setjmp and __setjmp
> >    symbols.  I suspect there is a macosx version dependency to the
> >    name mangling issue we need to work out.(not committed)
> 
> Do you mean that the following call would work ?
> 
> void foo () { }
> 
> int main ()
> {
>   (void) (*p) () = _foo;
>   (*p) ();
> }
> 

Actaully, I just did _setjmp(env) in plttest.c.  I can try the above,
but it would seem sure to work.  This was on the older macosx box,
however, which has since been upgraded.  Will try to double check
this. 

> > 3) No root nor tcl/tk on the machine in question, so I cannot
> >    reproduce this issue, but I don't see where my_free and my_malloc
> >    appear in o/alloc.c????  Am I missing something dumb?
> 
> To the best of my understanding, the default behavior for gcl on Linux
> is to override libc's default malloc/free routines. This is something
> that cannot be done easily on Mac OS X (see README.macosx) : we simply
> cannot override the system's default malloc. On Mac OS X, malloc
> defaults to calling a low level memory allocation routine. For most
> applications, the user doesn't have to care about this low level
> memory allocation routine : the system provides a default allocation
> routine transparently. However, in gcl, we provide our ow low level
> memory allocation routine which is simply a wrapper around malloc
> defined in o/alloc.c. Therefore, what we in h/powerpc-macosx.h do is :
> 
> #undef malloc
> #define malloc my_malloc
> 
> typical call the system's default malloc -> call to our low level
> memory management routine (defined in o/unexmacosx.c) -> call to gcl's
> custom memory allocation routine (defined in o/alloc.c) whose named is
> changed from malloc to my_malloc
> 
> Therefore, we have a symbol called my_malloc in o/alloc.c (try nm |
> grep my_malloc on o/alloc.o).
> 

OK, let me see if I understand -- calls to malloc in, say, libc's
printf wind up calling libc my_malloc which is overriden by our
my_malloc, so that no external dll malloc'ed memory might get placed
in an unknown location to interfere with GCL's own mm system, yes?
Curious as to how my_malloc could be overriden, but not malloc.

In any case, should this not be the case, and libc/printf malloc not
touch any GCL routine, it would appear we could use any name for
my_malloc and avoid prototype collisions, though we would be in dire
peril if we did not ensure in some way that the former would not
collide with the latter.

> > Will look at axiom, acl2, and cvs head next.  May I request:
> >
> > 1) That we elide the diagnostic material output on save system?  This
> >    might alarm the typical user.  BTW, have confirmed that the old
> >    save-system bug we were chasing in 2.6.6 is gone, or at least
> >    intermittent :-).
> 
> OK, I'll do something like :
> #define VERBOSE
> 

Thanks!  Again, this could go in both branch Version_2_6_8pre and
HEAD, if you would not mind.

> > 2) That we see about scaling the heap size from configure like on
> >    other platforms?
> 
> Do you mean : is the regular scheme used to scale the heap size on
> other platforms likely to work on Mac OS X ? I bet so.
> 

Here is where I thought configure would be unable to pass big heap
requests down into the code (unexmacosx.c):

/* This used to be the size of the heap, but this is no longer used.  */
#define BIG_HEAP_SIZE 0x50000000

Doesn't this prohibit a 1Gb heap?

BTW, do you approve of Satoshi's patch to mach-o-reloc.c?

Take care, and thanks as always!

> Aurelien
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah