Jan Djärv wrote:
Larry Hall wrote:
Jan DjÃrv wrote:
Larry Hall wrote:
Jan D. wrote:
It seems that when Emacs defines its own malloc and friends, memalign
returns ENOSYS. But emacs defines its own memalign as well. Shouldn't
that one be called?
Seems like it though it sounds like something that would be controlled
by the emacs configure script to me.
I don't follow. How can the Emacs configure script make sure the Emacs
supplied memalign is called by glib?
Ah, sorry. I missed that you were referring to glib. I agree that
there should be some consistency here. Perhaps things would work
better if Emacs
used none of it's own m* implementations. That's just a WAG. I
really have no experience with the Emacs code base. But it does sound
to me like this would be Emacs configurable at least. ;-)
I'll try without Emacs own malloc. But dynamic linking on w32 seems
strange to me, why is not Emacs own memalign called by glib?
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.
--
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/
