[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: Patch for gcl-2.6.7 on MacOSX(10.4.2) to build maxim
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] Re: Patch for gcl-2.6.7 on MacOSX(10.4.2) to build maxima-5.9.[12] and so on. |
Date: |
08 Dec 2005 18:10:06 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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