Larry Hall wrote:
> Jan DjÃrv wrote:
>
> Yes it does thanks for the explanation. Cygwin has some mechanism that
> makes
> it possible for a program to supply its own malloc/free and friends I
> think
> (malloc_wrapper.cc). Would it be hard to also handle memalign/valloc and
> later posix_memalign in the same fashion?
>
>
>
> It already handles memalign/valloc.
Are you talking about the released cygwin version? It does not handle malloc
the same as memalign, I see in malloc_wrapper.c:
extern "C" void *
malloc (size_t size)
{
void *res;
export_malloc_called = 1;
if (!use_internal_malloc)
res = user_data->malloc (size);
else
...
and
extern "C" void *
memalign (size_t alignment, size_t bytes)
{
void *res;
if (!use_internal_malloc)
{
set_errno (ENOSYS);
res = NULL;
}
>
>
> Would I be correct in assuming that such an addition would make glib call
> the
> Emacs versions?
>
>
>
> I suppose. But if Emacs is modular enough to provide its calls as a
> (import) library or object file, you can just list this on the link line
> after glib and get the same affect for Emacs/glib. This may be easier
> for you.
That would have to come from someone that cares alot about Emacs + Gtk+ on
cygwin. I'm just trying to find a simple solution, as it seems now, we will
disable Gtk+ on cygwin.
BTW, I tried to put to put the object file that contain malloc/memalign after
the Gtk+ libraries, and it didn't work. Glib does not call the Emacs supplied
memalign in this case either.
Jan D.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
