Building without Emacs malloc, possible?

Building without Emacs malloc, possible?

[Jan Djärv]

Hello.

What is the status of building without Emac malloc?  There are some problems 
on cygwin + Gtk.  Basically Gtk+ (glib actually) calls memalign, but on cygwin 
this does not call the Emacs supplied memalign, but cygwins own.  Since malloc 
is the one Emacs has, cygwin memalign refuses to work.  I don't know why the 
Emace memalign is not called, dynamic libraries on W32 seems to behave strange 
in this regard.

One solution would be for Emacs to not use its own malloc, but that gives 
compilation errors.  I don't have the errors here, but they are unresolved 
symbols in vm-limit.c.

So, the question is what is need to compile on cygwin without Emacs malloc? I 
just added

#define SYSTEM_MALLOC

to s/cygwin.h.  Apparently something more is needed.

	Jan D.

Re: Building without Emacs malloc, possible?

[Eli Zaretskii]

> Date: Wed, 21 Feb 2007 21:31:17 +0100
> From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <jan.h.d@swipnet.se>
> 
> What is the status of building without Emac malloc?  There are some problems 
> on cygwin + Gtk.  Basically Gtk+ (glib actually) calls memalign, but on cygwin 
> this does not call the Emacs supplied memalign, but cygwins own.  Since malloc 
> is the one Emacs has, cygwin memalign refuses to work.  I don't know why the 
> Emace memalign is not called, dynamic libraries on W32 seems to behave strange 
> in this regard.

That is very unfortunate.  Using system malloc will cause Emacs to
grow in its footprint much more than it does with gmalloc, possibly an
unlimited growth.  Did you try asking for advice on the Cygwin mailing
list?

> One solution would be for Emacs to not use its own malloc, but that gives 
> compilation errors.  I don't have the errors here, but they are unresolved 
> symbols in vm-limit.c.
> 
> So, the question is what is need to compile on cygwin without Emacs malloc? I 
> just added
> 
> #define SYSTEM_MALLOC
> 
> to s/cygwin.h.  Apparently something more is needed.

Defining SYSTEM_MALLOC ought to be enough.  What errors do you see?
Do the same errors happen when you try building with SYSTEM_MALLOC on
GNU/Linux?

Btw, I think you need to "make distclean" and reconfigure after adding
SYSTEM_MALLOC; maybe you didn't, and that's the reason for the
problems?

Re: Building without Emacs malloc, possible?

[Jan Djärv]

Eli Zaretskii skrev:
>> Date: Wed, 21 Feb 2007 21:31:17 +0100
>> From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <jan.h.d@swipnet.se>
>>
>> What is the status of building without Emac malloc?  There are some problems 
>> on cygwin + Gtk.  Basically Gtk+ (glib actually) calls memalign, but on cygwin 
>> this does not call the Emacs supplied memalign, but cygwins own.  Since malloc 
>> is the one Emacs has, cygwin memalign refuses to work.  I don't know why the 
>> Emace memalign is not called, dynamic libraries on W32 seems to behave strange 
>> in this regard.
> 
> That is very unfortunate.  Using system malloc will cause Emacs to
> grow in its footprint much more than it does with gmalloc, possibly an
> unlimited growth.  Did you try asking for advice on the Cygwin mailing
> list?

Yes, the advice was that Emacs should not use its own malloc in this case.  If 
that works, I'll add a configure check so that Emacs uses its own malloc on 
cygwin except when Gtk+ is used.  I still don't understand why the Emacs 
supplied memalign doesn't get called.

> 
>> One solution would be for Emacs to not use its own malloc, but that gives 
>> compilation errors.  I don't have the errors here, but they are unresolved 
>> symbols in vm-limit.c.
>>
>> So, the question is what is need to compile on cygwin without Emacs malloc? I 
>> just added
>>
>> #define SYSTEM_MALLOC
>>
>> to s/cygwin.h.  Apparently something more is needed.
> 
> Defining SYSTEM_MALLOC ought to be enough.  What errors do you see?
> Do the same errors happen when you try building with SYSTEM_MALLOC on
> GNU/Linux?
> 
> Btw, I think you need to "make distclean" and reconfigure after adding
> SYSTEM_MALLOC; maybe you didn't, and that's the reason for the
> problems?

I'll try again with that when I get access to the w32 machine again.  Thanks 
for the advice.

	Jan D.

Re: Building without Emacs malloc, possible?

[Eli Zaretskii]

> Date: Thu, 22 Feb 2007 07:57:59 +0100
> From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <jan.h.d@swipnet.se>
> Cc: emacs-devel@gnu.org
> > 
> > That is very unfortunate.  Using system malloc will cause Emacs to
> > grow in its footprint much more than it does with gmalloc, possibly an
> > unlimited growth.  Did you try asking for advice on the Cygwin mailing
> > list?
> 
> Yes, the advice was that Emacs should not use its own malloc in this case.

Not a very useful advice, IMO.  But then what else can we hope for,
since there's no maintainer of Cygwin Emacs?

Re: Building without Emacs malloc, possible?

[Jan D.]

Eli Zaretskii wrote:
> Defining SYSTEM_MALLOC ought to be enough. What errors do you see?
> Do the same errors happen when you try building with SYSTEM_MALLOC on
> GNU/Linux?
>
> Btw, I think you need to "make distclean" and reconfigure after adding
> SYSTEM_MALLOC; maybe you didn't, and that's the reason for the
> problems?
>   

I did make distclean, reconfigured, and I still get this:

vm-limit.o: In function `check_memory_limits':
/home/jhd/src/emacs-22.0.93/src/vm-limit.c:185: undefined reference to 
`___morecore'
vm-limit.o: In function `memory_warnings':
/home/jhd/src/emacs-22.0.93/src/vm-limit.c:259: undefined reference to 
`___after_morecore_hook'

I see this in src/Makefile.in:

#ifdef CYGWIN
/* Cygwin differs because of its unexec(). */
otherobj= $(termcapobj) $(gmallocobj) $(rallocobj) lastfile.o vm-limit.o 
$(allocaobj) $(widgetobj) $(LIBOBJS)
#else
otherobj= $(termcapobj) lastfile.o $(mallocobj) $(allocaobj) 
$(widgetobj) $(LIBOBJS)
#endif

so apparently the solution is more complex.  Maybe we just should say 
that Gtk+ and cygwin is not possible?

    Jan D.

Re: Building without Emacs malloc, possible?

[Eli Zaretskii]

> Date: Thu, 22 Feb 2007 19:48:12 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> Cc: emacs-devel@gnu.org
> 
> vm-limit.o: In function `check_memory_limits':
> /home/jhd/src/emacs-22.0.93/src/vm-limit.c:185: undefined reference to 
> `___morecore'
> vm-limit.o: In function `memory_warnings':
> /home/jhd/src/emacs-22.0.93/src/vm-limit.c:259: undefined reference to 
> `___after_morecore_hook'
> 
> I see this in src/Makefile.in:
> 
> #ifdef CYGWIN
> /* Cygwin differs because of its unexec(). */
> otherobj= $(termcapobj) $(gmallocobj) $(rallocobj) lastfile.o vm-limit.o 
> $(allocaobj) $(widgetobj) $(LIBOBJS)
> #else
> otherobj= $(termcapobj) lastfile.o $(mallocobj) $(allocaobj) 
> $(widgetobj) $(LIBOBJS)
> #endif
> 
> so apparently the solution is more complex.

Yes, Makefile.in should probably use a different list of object files
when SYSTEM_MALLOC is used in the Cygwin build.

> Maybe we just should say that Gtk+ and cygwin is not possible?

I'm fine with that, since no one seems to care about the Cygwin build
enough to actively maintain it.

Thanks for working on this.

Re: Building without Emacs malloc, possible?

[Stefan Monnier]

> What is the status of building without Emac malloc?  There are some problems
> on cygwin + Gtk.  Basically Gtk+ (glib actually) calls memalign, but on
> cygwin this does not call the Emacs supplied memalign, but cygwins own.
> Since malloc is the one Emacs has, cygwin memalign refuses to work.  I don't
> know why the Emace memalign is not called, dynamic libraries on W32 seems to
> behave strange in this regard.

BTW, isn't the problem that Emacs uses `posix_memalign' because it's found
in libc, even though its own malloc doesn't provide it?


        Stefan

Re: Building without Emacs malloc, possible?

[Jason Rumney]

Stefan Monnier wrote:
> BTW, isn't the problem that Emacs uses `posix_memalign' because it's found
> in libc, even though its own malloc doesn't provide it?
>   
For that to only happen when GTK is included, posix_memalign would have 
to be exported by the GTK libraries, not by the standard libraries.

I think the original diagnosis is right. Windows DLLs are linked to any 
libraries they need at build time, so functions like malloc cannot be 
overridden by the calling program.

Re: Building without Emacs malloc, possible?

[Jan Djärv]

Jason Rumney skrev:
> Stefan Monnier wrote:
>> BTW, isn't the problem that Emacs uses `posix_memalign' because it's
>> found
>> in libc, even though its own malloc doesn't provide it?
>>   
> For that to only happen when GTK is included, posix_memalign would have
> to be exported by the GTK libraries, not by the standard libraries.
> 
> I think the original diagnosis is right. Windows DLLs are linked to any
> libraries they need at build time, so functions like malloc cannot be
> overridden by the calling program.
> 

Cygwin has some kind of hack to make sure the malloc called is the one a
program supplies, if any.  Unfortunately they don't include memalign in that
hack, only malloc/calloc/realloc/free.

I'm not familiar with the unexec used on cygwin, but it looks like it relies
on the Emacs supplied malloc.

	Jan D.

Re: Building without Emacs malloc, possible?

[Jan Djärv]

Stefan Monnier skrev:
>> What is the status of building without Emac malloc?  There are some problems
>> on cygwin + Gtk.  Basically Gtk+ (glib actually) calls memalign, but on
>> cygwin this does not call the Emacs supplied memalign, but cygwins own.
>> Since malloc is the one Emacs has, cygwin memalign refuses to work.  I don't
>> know why the Emace memalign is not called, dynamic libraries on W32 seems to
>> behave strange in this regard.
> 
> BTW, isn't the problem that Emacs uses `posix_memalign' because it's found
> in libc, even though its own malloc doesn't provide it?

I've been told that it is not in the cygwin libc, except for newer snapshots.
 I've stepped in the glib code with gdb, and memalign is indeed called.

	Jan D.