Re: [ANNOUNCEMENT] Uploads for 12 August

Re: [ANNOUNCEMENT] Uploads for 12 August

[Angelo Graziosi]

Il 13/08/2013 11.52, Angelo Graziosi ha scritto:
> Yaakov wrote:
>> The following packages (and their subpackages) have been updated for
>> both arches:
>
> After this update my GTK builds of Emacs trunk do not work any more. For
> example, the bootstrap of rev. 113816 I did yesterday and that worked
> fine up to before this update, now fails so:
>
> $ emacs -Q &
> [1] 3044
>
> ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes
> (alignment: 512): Function not implemented
>
>
> [1]+  Aborted                 (core dumped) emacs -Q
>
>
> So, after this update, I tried a new bootstrap (rev.113838) but id fails
> in the same manner:
>
> if test "no" = "yes"; then \
>    rm -f bootstrap-emacs.exe; \
>    ln temacs.exe bootstrap-emacs.exe; \
> else \
>    `/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \
>    test "X" = X ||  -zex emacs.exe; \
>    mv -f emacs.exe bootstrap-emacs.exe; \
> fi
>
> ***MEMORY-ERROR***: [896]: GSlice: failed to allocate 504 bytes
> (alignment: 512): Function not implemented
>
> /bin/sh: line 7:   896 Aborted                 (core dumped)
> `/bin/pwd`/temacs --batch --load loadup bootstrap
> Makefile:835: recipe for target `bootstrap-emacs.exe' failed
> make[2]: *** [bootstrap-emacs.exe] Error 1
> make[2]: uscita dalla directory "/work/emacs/Work/src"
> Makefile:379: recipe for target `src' failed
> make[1]: *** [src] Error 2
> make[1]: uscita dalla directory "/work/emacs/Work"
> Makefile:1040: recipe for target `bootstrap' failed
> make: *** [bootstrap] Error 2
> build-emacs.sh: Bootstrap failure...
>
>
> Probably this issue affects also the Cygwin (GTK) package of Emacs..
>
> It seems that the workaround is to start Emacs with G_SLICE=always-malloc,
>
> $ G_SLICE=always-malloc emacs -Q &
>
>
> Ken, wasn't this issue fixed upstream some time ago?


Just for the record, I can reproduce the same issue with emacs-x11 from 
Cygwin package.

>
> Ciao,
>   Angelo.

PS. My previous replay was sent to the wrong mailing list... :(
   Sorry!

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: [ANNOUNCEMENT] Uploads for 12 August

[Ken Brown]

On 8/13/2013 8:08 AM, Angelo Graziosi wrote:
> Il 13/08/2013 11.52, Angelo Graziosi ha scritto:
>> Yaakov wrote:
>>> The following packages (and their subpackages) have been updated for
>>> both arches:
>>
>> After this update my GTK builds of Emacs trunk do not work any more. For
>> example, the bootstrap of rev. 113816 I did yesterday and that worked
>> fine up to before this update, now fails so:
>>
>> $ emacs -Q &
>> [1] 3044
>>
>> ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes
>> (alignment: 512): Function not implemented
>>
>>
>> [1]+  Aborted                 (core dumped) emacs -Q
>>
>>
>> So, after this update, I tried a new bootstrap (rev.113838) but id fails
>> in the same manner:
>>
>> if test "no" = "yes"; then \
>>    rm -f bootstrap-emacs.exe; \
>>    ln temacs.exe bootstrap-emacs.exe; \
>> else \
>>    `/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \
>>    test "X" = X ||  -zex emacs.exe; \
>>    mv -f emacs.exe bootstrap-emacs.exe; \
>> fi
>>
>> ***MEMORY-ERROR***: [896]: GSlice: failed to allocate 504 bytes
>> (alignment: 512): Function not implemented
>>
>> /bin/sh: line 7:   896 Aborted                 (core dumped)
>> `/bin/pwd`/temacs --batch --load loadup bootstrap
>> Makefile:835: recipe for target `bootstrap-emacs.exe' failed
>> make[2]: *** [bootstrap-emacs.exe] Error 1
>> make[2]: uscita dalla directory "/work/emacs/Work/src"
>> Makefile:379: recipe for target `src' failed
>> make[1]: *** [src] Error 2
>> make[1]: uscita dalla directory "/work/emacs/Work"
>> Makefile:1040: recipe for target `bootstrap' failed
>> make: *** [bootstrap] Error 2
>> build-emacs.sh: Bootstrap failure...
>>
>>
>> Probably this issue affects also the Cygwin (GTK) package of Emacs..
>>
>> It seems that the workaround is to start Emacs with
>> G_SLICE=always-malloc,
>>
>> $ G_SLICE=always-malloc emacs -Q &
>>
>>
>> Ken, wasn't this issue fixed upstream some time ago?

Yes.  The fix was to add the following for the Cygwin build, very early 
in main():

   setenv ("G_SLICE", "always-malloc", 1);

I don't know why this no longer works.  Maybe Glib now does its memory 
management initialization before emacs's main() is entered.

Yaakov, is there any chance that you could patch Glib to do the 
equivalent of G_SLICE=always-malloc on Cygwin?  This isn't really an 
emacs issue.  It would affect any GTK application that provides its own 
malloc rather than using Cygwin's malloc.  (But emacs is probably the 
only such application in the distro.)

An alternative to patching Glib would be to fix the problem directly in 
Cygwin, but I don't know how hard that is and whether Corinna and cgf 
are interested.  The issue, as I understand it, is this: Cygwin allows 
programs to supply their own malloc but not their own memalign.  Glib 
calls memalign, which becomes Cygwin's memalign, which returns ENOSYS 
when Cygwin's malloc is not being used.

There was a long discussion about this on the Cygwin mailing list in 
2007.  The thread starts at

   http://cygwin.com/ml/cygwin/2007-02/msg00469.html

and continues at

   http://cygwin.com/ml/cygwin/2007-02/msg00503.html

and did not resolve the issue.

Ken




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: [ANNOUNCEMENT] Uploads for 12 August

[Ken Brown]

On 8/13/2013 10:13 AM, Ken Brown wrote:
> On 8/13/2013 8:08 AM, Angelo Graziosi wrote:
>> Il 13/08/2013 11.52, Angelo Graziosi ha scritto:
>>> Yaakov wrote:
>>>> The following packages (and their subpackages) have been updated for
>>>> both arches:
>>>
>>> After this update my GTK builds of Emacs trunk do not work any more. For
>>> example, the bootstrap of rev. 113816 I did yesterday and that worked
>>> fine up to before this update, now fails so:
>>>
>>> $ emacs -Q &
>>> [1] 3044
>>>
>>> ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes
>>> (alignment: 512): Function not implemented
>>>
>>>
>>> [1]+  Aborted                 (core dumped) emacs -Q
>>>
>>>
>>> So, after this update, I tried a new bootstrap (rev.113838) but id fails
>>> in the same manner:
>>>
>>> if test "no" = "yes"; then \
>>>    rm -f bootstrap-emacs.exe; \
>>>    ln temacs.exe bootstrap-emacs.exe; \
>>> else \
>>>    `/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \
>>>    test "X" = X ||  -zex emacs.exe; \
>>>    mv -f emacs.exe bootstrap-emacs.exe; \
>>> fi
>>>
>>> ***MEMORY-ERROR***: [896]: GSlice: failed to allocate 504 bytes
>>> (alignment: 512): Function not implemented
>>>
>>> /bin/sh: line 7:   896 Aborted                 (core dumped)
>>> `/bin/pwd`/temacs --batch --load loadup bootstrap
>>> Makefile:835: recipe for target `bootstrap-emacs.exe' failed
>>> make[2]: *** [bootstrap-emacs.exe] Error 1
>>> make[2]: uscita dalla directory "/work/emacs/Work/src"
>>> Makefile:379: recipe for target `src' failed
>>> make[1]: *** [src] Error 2
>>> make[1]: uscita dalla directory "/work/emacs/Work"
>>> Makefile:1040: recipe for target `bootstrap' failed
>>> make: *** [bootstrap] Error 2
>>> build-emacs.sh: Bootstrap failure...
>>>
>>>
>>> Probably this issue affects also the Cygwin (GTK) package of Emacs..
>>>
>>> It seems that the workaround is to start Emacs with
>>> G_SLICE=always-malloc,
>>>
>>> $ G_SLICE=always-malloc emacs -Q &
>>>
>>>
>>> Ken, wasn't this issue fixed upstream some time ago?
>
> Yes.  The fix was to add the following for the Cygwin build, very early
> in main():
>
>    setenv ("G_SLICE", "always-malloc", 1);
>
> I don't know why this no longer works.  Maybe Glib now does its memory
> management initialization before emacs's main() is entered.
>
> Yaakov, is there any chance that you could patch Glib to do the
> equivalent of G_SLICE=always-malloc on Cygwin?  This isn't really an
> emacs issue.  It would affect any GTK application that provides its own
> malloc rather than using Cygwin's malloc.  (But emacs is probably the
> only such application in the distro.)
>
> An alternative to patching Glib would be to fix the problem directly in
> Cygwin, but I don't know how hard that is and whether Corinna and cgf
> are interested.  The issue, as I understand it, is this: Cygwin allows
> programs to supply their own malloc but not their own memalign.  Glib
> calls memalign, which becomes Cygwin's memalign, which returns ENOSYS
> when Cygwin's malloc is not being used.
>
> There was a long discussion about this on the Cygwin mailing list in
> 2007.  The thread starts at
>
>    http://cygwin.com/ml/cygwin/2007-02/msg00469.html
>
> and continues at
>
>    http://cygwin.com/ml/cygwin/2007-02/msg00503.html
>
> and did not resolve the issue.

While we're waiting for a good solution, I could quickly repackage 
emacs-X11 so that it supplies a wrapper script that sets 
G_SLICE=always-malloc before calling emacs-X11.  If people think that's 
a good idea, I should be able to do it later today.

Ken


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: [ANNOUNCEMENT] Uploads for 12 August

[Angelo Graziosi]

Ken Brown wrote:
> Yes. The fix was to add the following for the Cygwin build, very early in main():
>

Indeed.. I have verified that G_SLICE_ALWAYS_MALLOC is 1 in config.h so 
that in emacs.c

#ifdef G_SLICE_ALWAYS_MALLOC
   /* This is used by the Cygwin build.  */
   xputenv ("G_SLICE=always-malloc");
#endif

defines rightly G_SLICE...


>   setenv ("G_SLICE", "always-malloc", 1);
>
> I don't know why this no longer works. Maybe Glib now does its memory management initialization before emacs's main() is entered.

...evidently, this is not sufficient, too late: Emacs has already aborted

Probably, the problem is elsewhere...

Ciao,
Angelo.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: [ANNOUNCEMENT] Uploads for 12 August

[Yaakov (Cygwin/X)]

On 2013-08-13 09:13, Ken Brown wrote:
> Yes.  The fix was to add the following for the Cygwin build, very early
> in main():
>
>    setenv ("G_SLICE", "always-malloc", 1);
>
> I don't know why this no longer works.  Maybe Glib now does its memory
> management initialization before emacs's main() is entered.

Exactly; in glib-2.36, g_type_init has been moved to a ctor, which is 
automatically called before main(); hence, this setenv is too late now. 
  Mozilla software is also affected by this, see:

https://bugzilla.gnome.org/show_bug.cgi?id=687763
https://bugzilla.mozilla.org/show_bug.cgi?id=833117

and many others.  Firefox et al already use launcher scripts, so adding 
one more line won't be a big deal for them.

> Yaakov, is there any chance that you could patch Glib to do the
> equivalent of G_SLICE=always-malloc on Cygwin?  This isn't really an
> emacs issue.  It would affect any GTK application that provides its own
> malloc rather than using Cygwin's malloc.  (But emacs is probably the
> only such application in the distro.)

Given that the only programs which seem to be *practically* affected by 
this is our Emacs, and Firefox/Thunderbird/etc. (which we don't have 
yet), and using G_SLICE=always-malloc apparently affects performance, I 
don't think that would be an appropriate solution.

For now, I think you'll have to add a wrapper script.


Yaakov


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: [ANNOUNCEMENT] Uploads for 12 August

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

On Aug 13 13:09, Yaakov (Cygwin/X) wrote:
> On 2013-08-13 09:13, Ken Brown wrote:
> >Yes.  The fix was to add the following for the Cygwin build, very early
> >in main():
> >
> >   setenv ("G_SLICE", "always-malloc", 1);
> >
> >I don't know why this no longer works.  Maybe Glib now does its memory
> >management initialization before emacs's main() is entered.
> 
> Exactly; in glib-2.36, g_type_init has been moved to a ctor, which
> is automatically called before main(); hence, this setenv is too
> late now.  Mozilla software is also affected by this, see:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=687763
> https://bugzilla.mozilla.org/show_bug.cgi?id=833117
> 
> and many others.  Firefox et al already use launcher scripts, so
> adding one more line won't be a big deal for them.
> 
> >Yaakov, is there any chance that you could patch Glib to do the
> >equivalent of G_SLICE=always-malloc on Cygwin?  This isn't really an
> >emacs issue.  It would affect any GTK application that provides its own
> >malloc rather than using Cygwin's malloc.  (But emacs is probably the
> >only such application in the distro.)
> 
> Given that the only programs which seem to be *practically* affected
> by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't
> have yet), and using G_SLICE=always-malloc apparently affects
> performance, I don't think that would be an appropriate solution.
> 
> For now, I think you'll have to add a wrapper script.

Can anybody of you explain to me what the actual underlying problem is?
I mean, why this error message:

   ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes
   (alignment: 512): Function not implemented

What function is not implemented?  Is that something we can fix,
perhaps in the Cygwin DLL?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [ANNOUNCEMENT] Uploads for 12 August

[Charles Wilson]

On 8/13/2013 2:09 PM, Yaakov (Cygwin/X) wrote:
> For now, I think you'll have to add a wrapper script.

Which would cause issues (dos boxes, etc) when launching from a 
shortcut, unless you use run.exe or run2.exe.  With run2 (assuming the 
upcoming(?) release fixes the known issues), you can set environment 
vars directly in the xml script:


<?xml version="1.0" encoding="us-ascii"?>
<Run2Config
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:noNamespaceSchemaLocation="run2.xsd">
   <Global>
     <Environment>
       <Set var="G_SLICE" value="always-malloc"/>
     </Environment>
     <Target filename="/usr/bin/emacs.exe" startin="~">
       <Arg>...various stuff...</Arg>
       <Arg>...various stuff...</Arg>
       <Arg>...various stuff...</Arg>
     </Target>
   </Global>
</Run2Config>


...ought to work.  But there are still extant issues with run2 IIRC 
(been on vacation for a while so my memory from pre-vacation is still 
fuzzy).

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: [ANNOUNCEMENT] Uploads for 12 August

[Ken Brown]

On 8/13/2013 2:26 PM, Corinna Vinschen wrote:
> On Aug 13 13:09, Yaakov (Cygwin/X) wrote:
>> On 2013-08-13 09:13, Ken Brown wrote:
>>> Yes.  The fix was to add the following for the Cygwin build, very early
>>> in main():
>>>
>>>    setenv ("G_SLICE", "always-malloc", 1);
>>>
>>> I don't know why this no longer works.  Maybe Glib now does its memory
>>> management initialization before emacs's main() is entered.
>>
>> Exactly; in glib-2.36, g_type_init has been moved to a ctor, which
>> is automatically called before main(); hence, this setenv is too
>> late now.  Mozilla software is also affected by this, see:
>>
>> https://bugzilla.gnome.org/show_bug.cgi?id=687763
>> https://bugzilla.mozilla.org/show_bug.cgi?id=833117
>>
>> and many others.  Firefox et al already use launcher scripts, so
>> adding one more line won't be a big deal for them.
>>
>>> Yaakov, is there any chance that you could patch Glib to do the
>>> equivalent of G_SLICE=always-malloc on Cygwin?  This isn't really an
>>> emacs issue.  It would affect any GTK application that provides its own
>>> malloc rather than using Cygwin's malloc.  (But emacs is probably the
>>> only such application in the distro.)
>>
>> Given that the only programs which seem to be *practically* affected
>> by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't
>> have yet), and using G_SLICE=always-malloc apparently affects
>> performance, I don't think that would be an appropriate solution.
>>
>> For now, I think you'll have to add a wrapper script.
>
> Can anybody of you explain to me what the actual underlying problem is?
> I mean, why this error message:
>
>     ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes
>     (alignment: 512): Function not implemented
>
> What function is not implemented?  Is that something we can fix,
> perhaps in the Cygwin DLL?

It's memalign, or at least that's what it was in 2007.  See

   http://cygwin.com/ml/cygwin/2007-02/msg00678.html

Ken


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: [ANNOUNCEMENT] Uploads for 12 August

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]

On Aug 13 18:00, Ken Brown wrote:
> On 8/13/2013 2:26 PM, Corinna Vinschen wrote:
> >On Aug 13 13:09, Yaakov (Cygwin/X) wrote:
> >>On 2013-08-13 09:13, Ken Brown wrote:
> >>>Yaakov, is there any chance that you could patch Glib to do the
> >>>equivalent of G_SLICE=always-malloc on Cygwin?  This isn't really an
> >>>emacs issue.  It would affect any GTK application that provides its own
> >>>malloc rather than using Cygwin's malloc.  (But emacs is probably the
> >>>only such application in the distro.)
> >>
> >>Given that the only programs which seem to be *practically* affected
> >>by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't
> >>have yet), and using G_SLICE=always-malloc apparently affects
> >>performance, I don't think that would be an appropriate solution.
> >>
> >>For now, I think you'll have to add a wrapper script.
> >
> >Can anybody of you explain to me what the actual underlying problem is?
> >I mean, why this error message:
> >
> >    ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes
> >    (alignment: 512): Function not implemented
> >
> >What function is not implemented?  Is that something we can fix,
> >perhaps in the Cygwin DLL?
> 
> It's memalign, or at least that's what it was in 2007.  See
> 
>   http://cygwin.com/ml/cygwin/2007-02/msg00678.html

So it's using its own malloc but we don't support overriding other
functions besides malloc/realloc/calloc/free.

In theory we could do that in future.  We still have room for 10 (x86)
resp. 12 (x86_64) pointers in the per_process structure, which could be
used for this purpose.  This would only require applications which need
this feature to be rebuilt with the next Cygwin version providing these
pointers.

But we shouldn't waste those unused slots either, so the number of
overridable functions should be kept small.  In theory we have mallopt,
mallinfo, posix_memalign, memalign, and valloc.

I guess we can skip mallopt and mallinfo since they are pretty
seldomly used in user-provided malloc implementations.

Memalign is an old, deprecated function, so I wonder why it's used at
all.  GSlice should use posix_memalign instead.  Yaakov, is there an
option to use posix_memalign rather than memalign?

Anyway, that would be three extra pointers in the per_process structure,
for memalig, posic_memalign, and valloc, and we could get rid of the `if
(!use_internal) set_errno(ENOSYS);' in those functions and rather call
the user provided functions then.

Does that make sense?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [ANNOUNCEMENT] Uploads for 12 August

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3082 bytes --]

On Aug 14 10:10, Corinna Vinschen wrote:
> On Aug 13 18:00, Ken Brown wrote:
> > On 8/13/2013 2:26 PM, Corinna Vinschen wrote:
> > >On Aug 13 13:09, Yaakov (Cygwin/X) wrote:
> > >>On 2013-08-13 09:13, Ken Brown wrote:
> > >>>Yaakov, is there any chance that you could patch Glib to do the
> > >>>equivalent of G_SLICE=always-malloc on Cygwin?  This isn't really an
> > >>>emacs issue.  It would affect any GTK application that provides its own
> > >>>malloc rather than using Cygwin's malloc.  (But emacs is probably the
> > >>>only such application in the distro.)
> > >>
> > >>Given that the only programs which seem to be *practically* affected
> > >>by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't
> > >>have yet), and using G_SLICE=always-malloc apparently affects
> > >>performance, I don't think that would be an appropriate solution.
> > >>
> > >>For now, I think you'll have to add a wrapper script.
> > >
> > >Can anybody of you explain to me what the actual underlying problem is?
> > >I mean, why this error message:
> > >
> > >    ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes
> > >    (alignment: 512): Function not implemented
> > >
> > >What function is not implemented?  Is that something we can fix,
> > >perhaps in the Cygwin DLL?
> > 
> > It's memalign, or at least that's what it was in 2007.  See
> > 
> >   http://cygwin.com/ml/cygwin/2007-02/msg00678.html
> 
> So it's using its own malloc but we don't support overriding other
> functions besides malloc/realloc/calloc/free.
> 
> In theory we could do that in future.  We still have room for 10 (x86)
> resp. 12 (x86_64) pointers in the per_process structure, which could be
> used for this purpose.  This would only require applications which need
> this feature to be rebuilt with the next Cygwin version providing these
> pointers.

More precisely, they have to be rebuild using crt0.o from the next
Cygwin release, and they would have to run under the next Cygwin
release.  If you omit one step, you're back to the current behaviour.

> But we shouldn't waste those unused slots either, so the number of
> overridable functions should be kept small.  In theory we have mallopt,
> mallinfo, posix_memalign, memalign, and valloc.
> 
> I guess we can skip mallopt and mallinfo since they are pretty
> seldomly used in user-provided malloc implementations.
> 
> Memalign is an old, deprecated function, so I wonder why it's used at
> all.  GSlice should use posix_memalign instead.  Yaakov, is there an
> option to use posix_memalign rather than memalign?
> 
> Anyway, that would be three extra pointers in the per_process structure,
> for memalig, posic_memalign, and valloc, and we could get rid of the `if
> (!use_internal) set_errno(ENOSYS);' in those functions and rather call
> the user provided functions then.
> 
> Does that make sense?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [ANNOUNCEMENT] Uploads for 12 August

[Ken Brown]

On 8/14/2013 5:16 AM, Corinna Vinschen wrote:
> On Aug 14 10:10, Corinna Vinschen wrote:
>> On Aug 13 18:00, Ken Brown wrote:
>>> On 8/13/2013 2:26 PM, Corinna Vinschen wrote:
>>>> On Aug 13 13:09, Yaakov (Cygwin/X) wrote:
>>>>> On 2013-08-13 09:13, Ken Brown wrote:
>>>>>> Yaakov, is there any chance that you could patch Glib to do the
>>>>>> equivalent of G_SLICE=always-malloc on Cygwin?  This isn't really an
>>>>>> emacs issue.  It would affect any GTK application that provides its own
>>>>>> malloc rather than using Cygwin's malloc.  (But emacs is probably the
>>>>>> only such application in the distro.)
>>>>>
>>>>> Given that the only programs which seem to be *practically* affected
>>>>> by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't
>>>>> have yet), and using G_SLICE=always-malloc apparently affects
>>>>> performance, I don't think that would be an appropriate solution.
>>>>>
>>>>> For now, I think you'll have to add a wrapper script.
>>>>
>>>> Can anybody of you explain to me what the actual underlying problem is?
>>>> I mean, why this error message:
>>>>
>>>>     ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes
>>>>     (alignment: 512): Function not implemented
>>>>
>>>> What function is not implemented?  Is that something we can fix,
>>>> perhaps in the Cygwin DLL?
>>>
>>> It's memalign, or at least that's what it was in 2007.  See
>>>
>>>    http://cygwin.com/ml/cygwin/2007-02/msg00678.html
>>
>> So it's using its own malloc but we don't support overriding other
>> functions besides malloc/realloc/calloc/free.
>>
>> In theory we could do that in future.  We still have room for 10 (x86)
>> resp. 12 (x86_64) pointers in the per_process structure, which could be
>> used for this purpose.  This would only require applications which need
>> this feature to be rebuilt with the next Cygwin version providing these
>> pointers.
>
> More precisely, they have to be rebuild using crt0.o from the next
> Cygwin release, and they would have to run under the next Cygwin
> release.  If you omit one step, you're back to the current behaviour.
>
>> But we shouldn't waste those unused slots either, so the number of
>> overridable functions should be kept small.  In theory we have mallopt,
>> mallinfo, posix_memalign, memalign, and valloc.
>>
>> I guess we can skip mallopt and mallinfo since they are pretty
>> seldomly used in user-provided malloc implementations.
>>
>> Memalign is an old, deprecated function, so I wonder why it's used at
>> all.  GSlice should use posix_memalign instead.  Yaakov, is there an
>> option to use posix_memalign rather than memalign?

I just checked the glib source, and it does use posix_memalign if it's 
available.  I was quoting a 2007 discussion when I said it was memalign 
that GSlice wanted to use.

>> Anyway, that would be three extra pointers in the per_process structure,
>> for memalig, posic_memalign, and valloc, and we could get rid of the `if
>> (!use_internal) set_errno(ENOSYS);' in those functions and rather call
>> the user provided functions then.
>>
>> Does that make sense?

Yes.

Ken

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: [ANNOUNCEMENT] Uploads for 12 August

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3519 bytes --]

On Aug 14 06:28, Ken Brown wrote:
> On 8/14/2013 5:16 AM, Corinna Vinschen wrote:
> >On Aug 14 10:10, Corinna Vinschen wrote:
> >>On Aug 13 18:00, Ken Brown wrote:
> >>>On 8/13/2013 2:26 PM, Corinna Vinschen wrote:
> >>>>On Aug 13 13:09, Yaakov (Cygwin/X) wrote:
> >>>>>On 2013-08-13 09:13, Ken Brown wrote:
> >>>>>>Yaakov, is there any chance that you could patch Glib to do the
> >>>>>>equivalent of G_SLICE=always-malloc on Cygwin?  This isn't really an
> >>>>>>emacs issue.  It would affect any GTK application that provides its own
> >>>>>>malloc rather than using Cygwin's malloc.  (But emacs is probably the
> >>>>>>only such application in the distro.)
> >>>>>
> >>>>>Given that the only programs which seem to be *practically* affected
> >>>>>by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't
> >>>>>have yet), and using G_SLICE=always-malloc apparently affects
> >>>>>performance, I don't think that would be an appropriate solution.
> >>>>>
> >>>>>For now, I think you'll have to add a wrapper script.
> >>>>
> >>>>Can anybody of you explain to me what the actual underlying problem is?
> >>>>I mean, why this error message:
> >>>>
> >>>>    ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes
> >>>>    (alignment: 512): Function not implemented
> >>>>
> >>>>What function is not implemented?  Is that something we can fix,
> >>>>perhaps in the Cygwin DLL?
> >>>
> >>>It's memalign, or at least that's what it was in 2007.  See
> >>>
> >>>   http://cygwin.com/ml/cygwin/2007-02/msg00678.html
> >>
> >>So it's using its own malloc but we don't support overriding other
> >>functions besides malloc/realloc/calloc/free.
> >>
> >>In theory we could do that in future.  We still have room for 10 (x86)
> >>resp. 12 (x86_64) pointers in the per_process structure, which could be
> >>used for this purpose.  This would only require applications which need
> >>this feature to be rebuilt with the next Cygwin version providing these
> >>pointers.
> >
> >More precisely, they have to be rebuild using crt0.o from the next
> >Cygwin release, and they would have to run under the next Cygwin
> >release.  If you omit one step, you're back to the current behaviour.
> >
> >>But we shouldn't waste those unused slots either, so the number of
> >>overridable functions should be kept small.  In theory we have mallopt,
> >>mallinfo, posix_memalign, memalign, and valloc.
> >>
> >>I guess we can skip mallopt and mallinfo since they are pretty
> >>seldomly used in user-provided malloc implementations.
> >>
> >>Memalign is an old, deprecated function, so I wonder why it's used at
> >>all.  GSlice should use posix_memalign instead.  Yaakov, is there an
> >>option to use posix_memalign rather than memalign?
> 
> I just checked the glib source, and it does use posix_memalign if
> it's available.  I was quoting a 2007 discussion when I said it was
> memalign that GSlice wanted to use.

Given that, we should perhaps skip the memalign override.

> >>Anyway, that would be three extra pointers in the per_process structure,
> >>for memalig, posic_memalign, and valloc, and we could get rid of the `if
> >>(!use_internal) set_errno(ENOSYS);' in those functions and rather call
> >>the user provided functions then.
> >>
> >>Does that make sense?
> 
> Yes.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [ANNOUNCEMENT] Uploads for 12 August

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]

On Aug 14 12:53, Corinna Vinschen wrote:
> On Aug 14 06:28, Ken Brown wrote:
> > On 8/14/2013 5:16 AM, Corinna Vinschen wrote:
> > >On Aug 14 10:10, Corinna Vinschen wrote:
> > >>On Aug 13 18:00, Ken Brown wrote:
> > >>>On 8/13/2013 2:26 PM, Corinna Vinschen wrote:
> > >>>>What function is not implemented?  Is that something we can fix,
> > >>>>perhaps in the Cygwin DLL?
> > >>>
> > >>>It's memalign, or at least that's what it was in 2007.  See
> > >>>
> > >>>   http://cygwin.com/ml/cygwin/2007-02/msg00678.html
> > >>
> > >>So it's using its own malloc but we don't support overriding other
> > >>functions besides malloc/realloc/calloc/free.
> > >>
> > >>In theory we could do that in future.  We still have room for 10 (x86)
> > >>resp. 12 (x86_64) pointers in the per_process structure, which could be
> > >>used for this purpose.  This would only require applications which need
> > >>this feature to be rebuilt with the next Cygwin version providing these
> > >>pointers.
> > >
> > >More precisely, they have to be rebuild using crt0.o from the next
> > >Cygwin release, and they would have to run under the next Cygwin
> > >release.  If you omit one step, you're back to the current behaviour.
> > >
> > >>But we shouldn't waste those unused slots either, so the number of
> > >>overridable functions should be kept small.  In theory we have mallopt,
> > >>mallinfo, posix_memalign, memalign, and valloc.
> > >>
> > >>I guess we can skip mallopt and mallinfo since they are pretty
> > >>seldomly used in user-provided malloc implementations.
> > >>
> > >>Memalign is an old, deprecated function, so I wonder why it's used at
> > >>all.  GSlice should use posix_memalign instead.  Yaakov, is there an
> > >>option to use posix_memalign rather than memalign?
> > 
> > I just checked the glib source, and it does use posix_memalign if
> > it's available.  I was quoting a 2007 discussion when I said it was
> > memalign that GSlice wanted to use.
> 
> Given that, we should perhaps skip the memalign override.

On second (third? fourth?) thought, I think we should do this with
posix_memalign only.  valloc is just as obsolete as posix_memalign.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [ANNOUNCEMENT] Uploads for 12 August

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2779 bytes --]

On Aug 14 13:33, Corinna Vinschen wrote:
> On Aug 14 12:53, Corinna Vinschen wrote:
> > On Aug 14 06:28, Ken Brown wrote:
> > > On 8/14/2013 5:16 AM, Corinna Vinschen wrote:
> > > >On Aug 14 10:10, Corinna Vinschen wrote:
> > > >>On Aug 13 18:00, Ken Brown wrote:
> > > >>>On 8/13/2013 2:26 PM, Corinna Vinschen wrote:
> > > >>>>What function is not implemented?  Is that something we can fix,
> > > >>>>perhaps in the Cygwin DLL?
> > > >>>
> > > >>>It's memalign, or at least that's what it was in 2007.  See
> > > >>>
> > > >>>   http://cygwin.com/ml/cygwin/2007-02/msg00678.html
> > > >>
> > > >>So it's using its own malloc but we don't support overriding other
> > > >>functions besides malloc/realloc/calloc/free.
> > > >>
> > > >>In theory we could do that in future.  We still have room for 10 (x86)
> > > >>resp. 12 (x86_64) pointers in the per_process structure, which could be
> > > >>used for this purpose.  This would only require applications which need
> > > >>this feature to be rebuilt with the next Cygwin version providing these
> > > >>pointers.
> > > >
> > > >More precisely, they have to be rebuild using crt0.o from the next
> > > >Cygwin release, and they would have to run under the next Cygwin
> > > >release.  If you omit one step, you're back to the current behaviour.
> > > >
> > > >>But we shouldn't waste those unused slots either, so the number of
> > > >>overridable functions should be kept small.  In theory we have mallopt,
> > > >>mallinfo, posix_memalign, memalign, and valloc.
> > > >>
> > > >>I guess we can skip mallopt and mallinfo since they are pretty
> > > >>seldomly used in user-provided malloc implementations.
> > > >>
> > > >>Memalign is an old, deprecated function, so I wonder why it's used at
> > > >>all.  GSlice should use posix_memalign instead.  Yaakov, is there an
> > > >>option to use posix_memalign rather than memalign?
> > > 
> > > I just checked the glib source, and it does use posix_memalign if
> > > it's available.  I was quoting a 2007 discussion when I said it was
> > > memalign that GSlice wanted to use.
> > 
> > Given that, we should perhaps skip the memalign override.
> 
> On second (third? fourth?) thought, I think we should do this with
> posix_memalign only.  valloc is just as obsolete as posix_memalign.

I applied the patch to allow overriding posix_memalloc only, and I'm
building snapshots right now.  For testing, this requires to rebuild
either emacs, or glib, or both, I'm not sure.  Make sure to link against
the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [ANNOUNCEMENT] Uploads for 12 August

[Ken Brown]

On 8/14/2013 7:59 AM, Corinna Vinschen wrote:
> On Aug 14 13:33, Corinna Vinschen wrote:
>> On Aug 14 12:53, Corinna Vinschen wrote:
>>> On Aug 14 06:28, Ken Brown wrote:
>>>> On 8/14/2013 5:16 AM, Corinna Vinschen wrote:
>>>>> On Aug 14 10:10, Corinna Vinschen wrote:
>>>>>> On Aug 13 18:00, Ken Brown wrote:
>>>>>>> On 8/13/2013 2:26 PM, Corinna Vinschen wrote:
>>>>>>>> What function is not implemented?  Is that something we can fix,
>>>>>>>> perhaps in the Cygwin DLL?
>>>>>>>
>>>>>>> It's memalign, or at least that's what it was in 2007.  See
>>>>>>>
>>>>>>>    http://cygwin.com/ml/cygwin/2007-02/msg00678.html
>>>>>>
>>>>>> So it's using its own malloc but we don't support overriding other
>>>>>> functions besides malloc/realloc/calloc/free.
>>>>>>
>>>>>> In theory we could do that in future.  We still have room for 10 (x86)
>>>>>> resp. 12 (x86_64) pointers in the per_process structure, which could be
>>>>>> used for this purpose.  This would only require applications which need
>>>>>> this feature to be rebuilt with the next Cygwin version providing these
>>>>>> pointers.
>>>>>
>>>>> More precisely, they have to be rebuild using crt0.o from the next
>>>>> Cygwin release, and they would have to run under the next Cygwin
>>>>> release.  If you omit one step, you're back to the current behaviour.
>>>>>
>>>>>> But we shouldn't waste those unused slots either, so the number of
>>>>>> overridable functions should be kept small.  In theory we have mallopt,
>>>>>> mallinfo, posix_memalign, memalign, and valloc.
>>>>>>
>>>>>> I guess we can skip mallopt and mallinfo since they are pretty
>>>>>> seldomly used in user-provided malloc implementations.
>>>>>>
>>>>>> Memalign is an old, deprecated function, so I wonder why it's used at
>>>>>> all.  GSlice should use posix_memalign instead.  Yaakov, is there an
>>>>>> option to use posix_memalign rather than memalign?
>>>>
>>>> I just checked the glib source, and it does use posix_memalign if
>>>> it's available.  I was quoting a 2007 discussion when I said it was
>>>> memalign that GSlice wanted to use.
>>>
>>> Given that, we should perhaps skip the memalign override.
>>
>> On second (third? fourth?) thought, I think we should do this with
>> posix_memalign only.  valloc is just as obsolete as posix_memalign.
>
> I applied the patch to allow overriding posix_memalloc only, and I'm
> building snapshots right now.  For testing, this requires to rebuild
> either emacs, or glib, or both, I'm not sure.  Make sure to link against
> the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing.

Thanks.  It should only be emacs that needs rebuilding; glib doesn't 
supply its own malloc, but emacs does.  I'll test it and report back.

Ken

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: [ANNOUNCEMENT] Uploads for 12 August

[Ryan Johnson]

On 14/08/2013 7:59 AM, Corinna Vinschen wrote:
> On Aug 14 13:33, Corinna Vinschen wrote:
>> On Aug 14 12:53, Corinna Vinschen wrote:
>>> On Aug 14 06:28, Ken Brown wrote:
>>>> On 8/14/2013 5:16 AM, Corinna Vinschen wrote:
>>>>> On Aug 14 10:10, Corinna Vinschen wrote:
>>>>>> On Aug 13 18:00, Ken Brown wrote:
>>>>>>> On 8/13/2013 2:26 PM, Corinna Vinschen wrote:
>>>>>>>> What function is not implemented?  Is that something we can fix,
>>>>>>>> perhaps in the Cygwin DLL?
>>>>>>> It's memalign, or at least that's what it was in 2007.  See
>>>>>>>
>>>>>>>    http://cygwin.com/ml/cygwin/2007-02/msg00678.html
>>>>>> So it's using its own malloc but we don't support overriding other
>>>>>> functions besides malloc/realloc/calloc/free.
>>>>>>
>>>>>> In theory we could do that in future.  We still have room for 10 (x86)
>>>>>> resp. 12 (x86_64) pointers in the per_process structure, which could be
>>>>>> used for this purpose.  This would only require applications which need
>>>>>> this feature to be rebuilt with the next Cygwin version providing these
>>>>>> pointers.
>>>>> More precisely, they have to be rebuild using crt0.o from the next
>>>>> Cygwin release, and they would have to run under the next Cygwin
>>>>> release.  If you omit one step, you're back to the current behaviour.
>>>>>
>>>>>> But we shouldn't waste those unused slots either, so the number of
>>>>>> overridable functions should be kept small.  In theory we have mallopt,
>>>>>> mallinfo, posix_memalign, memalign, and valloc.
>>>>>>
>>>>>> I guess we can skip mallopt and mallinfo since they are pretty
>>>>>> seldomly used in user-provided malloc implementations.
>>>>>>
>>>>>> Memalign is an old, deprecated function, so I wonder why it's used at
>>>>>> all.  GSlice should use posix_memalign instead.  Yaakov, is there an
>>>>>> option to use posix_memalign rather than memalign?
>>>> I just checked the glib source, and it does use posix_memalign if
>>>> it's available.  I was quoting a 2007 discussion when I said it was
>>>> memalign that GSlice wanted to use.
>>> Given that, we should perhaps skip the memalign override.
>> On second (third? fourth?) thought, I think we should do this with
>> posix_memalign only.  valloc is just as obsolete as posix_memalign.
> I applied the patch to allow overriding posix_memalloc only, and I'm
> building snapshots right now.  For testing, this requires to rebuild
> either emacs, or glib, or both, I'm not sure.  Make sure to link against
> the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing.
Wait, it's "memalign" that's obsolete and "posix_memalign" that you 
added a patch for, right? The last couple of paragraphs were a little 
confusing...

Ryan


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: [ANNOUNCEMENT] Uploads for 12 August

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3066 bytes --]

On Aug 14 08:28, Ryan Johnson wrote:
> On 14/08/2013 7:59 AM, Corinna Vinschen wrote:
> >On Aug 14 13:33, Corinna Vinschen wrote:
> >>On Aug 14 12:53, Corinna Vinschen wrote:
> >>>On Aug 14 06:28, Ken Brown wrote:
> >>>>On 8/14/2013 5:16 AM, Corinna Vinschen wrote:
> >>>>>On Aug 14 10:10, Corinna Vinschen wrote:
> >>>>>>On Aug 13 18:00, Ken Brown wrote:
> >>>>>>>On 8/13/2013 2:26 PM, Corinna Vinschen wrote:
> >>>>>>>>What function is not implemented?  Is that something we can fix,
> >>>>>>>>perhaps in the Cygwin DLL?
> >>>>>>>It's memalign, or at least that's what it was in 2007.  See
> >>>>>>>
> >>>>>>>   http://cygwin.com/ml/cygwin/2007-02/msg00678.html
> >>>>>>So it's using its own malloc but we don't support overriding other
> >>>>>>functions besides malloc/realloc/calloc/free.
> >>>>>>
> >>>>>>In theory we could do that in future.  We still have room for 10 (x86)
> >>>>>>resp. 12 (x86_64) pointers in the per_process structure, which could be
> >>>>>>used for this purpose.  This would only require applications which need
> >>>>>>this feature to be rebuilt with the next Cygwin version providing these
> >>>>>>pointers.
> >>>>>More precisely, they have to be rebuild using crt0.o from the next
> >>>>>Cygwin release, and they would have to run under the next Cygwin
> >>>>>release.  If you omit one step, you're back to the current behaviour.
> >>>>>
> >>>>>>But we shouldn't waste those unused slots either, so the number of
> >>>>>>overridable functions should be kept small.  In theory we have mallopt,
> >>>>>>mallinfo, posix_memalign, memalign, and valloc.
> >>>>>>
> >>>>>>I guess we can skip mallopt and mallinfo since they are pretty
> >>>>>>seldomly used in user-provided malloc implementations.
> >>>>>>
> >>>>>>Memalign is an old, deprecated function, so I wonder why it's used at
> >>>>>>all.  GSlice should use posix_memalign instead.  Yaakov, is there an
> >>>>>>option to use posix_memalign rather than memalign?
> >>>>I just checked the glib source, and it does use posix_memalign if
> >>>>it's available.  I was quoting a 2007 discussion when I said it was
> >>>>memalign that GSlice wanted to use.
> >>>Given that, we should perhaps skip the memalign override.
> >>On second (third? fourth?) thought, I think we should do this with
> >>posix_memalign only.  valloc is just as obsolete as posix_memalign.
> >I applied the patch to allow overriding posix_memalloc only, and I'm
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> >building snapshots right now.  For testing, this requires to rebuild
> >either emacs, or glib, or both, I'm not sure.  Make sure to link against
> >the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing.
> Wait, it's "memalign" that's obsolete and "posix_memalign" that you
> added a patch for, right? The last couple of paragraphs were a
> little confusing...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [ANNOUNCEMENT] Uploads for 12 August

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

On Aug 14 16:05, Corinna Vinschen wrote:
> On Aug 14 08:28, Ryan Johnson wrote:
> > On 14/08/2013 7:59 AM, Corinna Vinschen wrote:
> > >On Aug 14 13:33, Corinna Vinschen wrote:
> > >>On Aug 14 12:53, Corinna Vinschen wrote:
> > >>>Given that, we should perhaps skip the memalign override.
> > >>On second (third? fourth?) thought, I think we should do this with
> > >>posix_memalign only.  valloc is just as obsolete as posix_memalign.

Oops.  Make that "valloc is just as obsolete as memalign."

> > >I applied the patch to allow overriding posix_memalloc only, and I'm
>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> > >building snapshots right now.  For testing, this requires to rebuild
> > >either emacs, or glib, or both, I'm not sure.  Make sure to link against
> > >the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing.
> > Wait, it's "memalign" that's obsolete and "posix_memalign" that you
> > added a patch for, right? The last couple of paragraphs were a
> > little confusing...

Sorry,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [ANNOUNCEMENT] Uploads for 12 August

[Ken Brown]

On 8/14/2013 8:14 AM, Ken Brown wrote:
> On 8/14/2013 7:59 AM, Corinna Vinschen wrote:
>> On Aug 14 13:33, Corinna Vinschen wrote:
>>> On Aug 14 12:53, Corinna Vinschen wrote:
>>>> On Aug 14 06:28, Ken Brown wrote:
>>>>> On 8/14/2013 5:16 AM, Corinna Vinschen wrote:
>>>>>> On Aug 14 10:10, Corinna Vinschen wrote:
>>>>>>> On Aug 13 18:00, Ken Brown wrote:
>>>>>>>> On 8/13/2013 2:26 PM, Corinna Vinschen wrote:
>>>>>>>>> What function is not implemented?  Is that something we can fix,
>>>>>>>>> perhaps in the Cygwin DLL?
>>>>>>>>
>>>>>>>> It's memalign, or at least that's what it was in 2007.  See
>>>>>>>>
>>>>>>>>    http://cygwin.com/ml/cygwin/2007-02/msg00678.html
>>>>>>>
>>>>>>> So it's using its own malloc but we don't support overriding other
>>>>>>> functions besides malloc/realloc/calloc/free.
>>>>>>>
>>>>>>> In theory we could do that in future.  We still have room for 10
>>>>>>> (x86)
>>>>>>> resp. 12 (x86_64) pointers in the per_process structure, which
>>>>>>> could be
>>>>>>> used for this purpose.  This would only require applications
>>>>>>> which need
>>>>>>> this feature to be rebuilt with the next Cygwin version providing
>>>>>>> these
>>>>>>> pointers.
>>>>>>
>>>>>> More precisely, they have to be rebuild using crt0.o from the next
>>>>>> Cygwin release, and they would have to run under the next Cygwin
>>>>>> release.  If you omit one step, you're back to the current behaviour.
>>>>>>
>>>>>>> But we shouldn't waste those unused slots either, so the number of
>>>>>>> overridable functions should be kept small.  In theory we have
>>>>>>> mallopt,
>>>>>>> mallinfo, posix_memalign, memalign, and valloc.
>>>>>>>
>>>>>>> I guess we can skip mallopt and mallinfo since they are pretty
>>>>>>> seldomly used in user-provided malloc implementations.
>>>>>>>
>>>>>>> Memalign is an old, deprecated function, so I wonder why it's
>>>>>>> used at
>>>>>>> all.  GSlice should use posix_memalign instead.  Yaakov, is there an
>>>>>>> option to use posix_memalign rather than memalign?
>>>>>
>>>>> I just checked the glib source, and it does use posix_memalign if
>>>>> it's available.  I was quoting a 2007 discussion when I said it was
>>>>> memalign that GSlice wanted to use.
>>>>
>>>> Given that, we should perhaps skip the memalign override.
>>>
>>> On second (third? fourth?) thought, I think we should do this with
>>> posix_memalign only.  valloc is just as obsolete as posix_memalign.
>>
>> I applied the patch to allow overriding posix_memalloc only, and I'm
>> building snapshots right now.  For testing, this requires to rebuild
>> either emacs, or glib, or both, I'm not sure.  Make sure to link against
>> the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing.
>
> Thanks.  It should only be emacs that needs rebuilding; glib doesn't
> supply its own malloc, but emacs does.  I'll test it and report back.

Success!  Thanks very much for the quick fix.  I've got new emacs 
packages ready to go for both 32-bit and 64-bit.  Do you expect to 
release cygwin-1.7.24 soon?  If not, I'll upload the new packages as 
test releases for anyone who wants to install the snapshot.

Ken

P.S. For anyone (like Angelo) who wants to build the emacs trunk, I need 
to patch gmalloc.c upstream before the fix will take effect.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: [ANNOUNCEMENT] Uploads for 12 August

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

On Aug 14 11:55, Ken Brown wrote:
> On 8/14/2013 8:14 AM, Ken Brown wrote:
> >On 8/14/2013 7:59 AM, Corinna Vinschen wrote:
> >>I applied the patch to allow overriding posix_memalloc only, and I'm
> >>building snapshots right now.  For testing, this requires to rebuild
> >>either emacs, or glib, or both, I'm not sure.  Make sure to link against
> >>the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing.
> >
> >Thanks.  It should only be emacs that needs rebuilding; glib doesn't
> >supply its own malloc, but emacs does.  I'll test it and report back.
> 
> Success!  Thanks very much for the quick fix.  I've got new emacs
> packages ready to go for both 32-bit and 64-bit.  Do you expect to
> release cygwin-1.7.24 soon?  If not, I'll upload the new packages as
> test releases for anyone who wants to install the snapshot.

Thanks for testing.  I'll update to 1.7.24 tomorrow.  We have lots of
unused version numbers left ;)


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [ANNOUNCEMENT] Uploads for 12 August

[Angelo Graziosi]

Ken Brown wrote:
> P.S. For anyone (like Angelo) who wants to build the emacs trunk, I need to patch gmalloc.c upstream before the fix will take effect.

Thanks, I will wait for your patches and the Cygwin upgrade.

Corin.. oops... Mum wrote it will be released tomorrow.. ;-)


Ciao,
  Angelo.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: [ANNOUNCEMENT] Uploads for 12 August

[Enrico Forestieri]

Yaakov writes:
> 
> The following packages (and their subpackages) have been updated for 
> both arches:
[...]
> * gamin-0.1.10-14

After this update, all programs using libfam crash.
For example, the test program that can be also found here:
http://www.fifi.org/doc/libfam-dev/examples/test.c++.gz

It seems that the crash is due to compiling with optimization.
Indeed, adding CFLAGS+=" -O0" to the cygport file and recompiling
resolves the issue.

-- 
Enrico


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

[ANNOUNCEMENT] Uploads for 12 August

[Yaakov (Cygwin/X)]

The following packages (and their subpackages) have been updated for 
both arches:

* at-spi2-atk-2.8.1-1
* at-spi2-core-2.8.0-1
* atk1.0-2.8.0-1
* dconf-0.16.1-1
* font-cantarell-otf-0.0.13-1
* fontconfig-2.10.93-1
* gamin-0.1.10-14
* GConf2-3.2.6-2
* gcr-3.8.2-1
* gdk-pixbuf2.0-2.28.2-1
* glib2.0-2.36.4-1
* glib2.0-networking-2.36.2-1
* gnome-common-3.7.4-2
* gnome-icon-theme-3.8.3-1
* gnome-keyring-3.8.2-1
* gnome-themes-standard-3.8.3-1
* gobject-introspection-1.36.0-1
* graphite2-1.2.3-1
* gsettings-desktop-schemas-3.8.2-1
* gstreamer1.0-1.0.9-1
* gstreamer1.0-plugins-base-1.0.9-1
* gstreamer1.0-plugins-good-1.0.9-1
* gtk-doc-1.19-1
* gtk2.0-2.24.20-1
* gtk3-3.8.2-1
* gvfs-1.16.3-1
* harfbuzz-0.9.19-1
* libgnome-keyring-3.8.0-1
* libgsf-1.14.28-1
* libsecret1-0.15-1
* libsoup2.4-2.42.2-1
* nspr-4.9.6-1
* pango1.0-1.34.1-1
* pcre-8.33-1
* perl-Clone-0.34-1
* pixman-0.30.2-1
* python-gi-3.8.3-1
* python3-gi-3.8.3-1
* vala-0.20.1-1
* xorg-cf-files-1.0.5-2
* yelp-xsl-3.8.1-1

This update brings the GNOME components in the distro up to the latest 
stable release.

-- 

Yaakov
Cygwin/X


CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO
======================================

If you want to unsubscribe from the cygwin-xfree-announce mailing list,
please use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message.  Send email to the address specified
there.  It will be in the format:

cygwin-xfree-announce-unsubscribe-you=yourdomain.com@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/