This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: FW: Re: [emacs_user@hotmail.com: ***MEMORY-ERROR***: emacs[5172]: GSlice: failed
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/