FW: Re: [emacs_user@hotmail.com: ***MEMORY-ERROR***: emacs[5172]: GSlice: failed

[Larry Hall (Cygwin)]

Jan Djärv wrote:
> Larry Hall wrote:
> 
>> With DLLs, symbol resolution happens at link time, not runtime.  The only
>> way to avoid this fact is to use dllopen (in Cygwin) or LoadLibrary (in
>> Win32) and friends.  If glib needs to reference something in Emacs, an
>> import library with these symbol resolutions must appear after the reference
>> to glib on the link line.  I don't know if that explains why Emacs' memalign
>> is not called from glib but it hopefully clarifies the DLL linking issue
>> some.
> 
> 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.


> 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.



-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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/