Re: [ANNOUNCEMENT] Uploads for 12 August
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 pgpArzq541Qn1.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
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 pgpNEXZAvqeCa.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
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
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 pgpfsM6KM4miS.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
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 pgpa98jiOgKrE.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
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 pgp0luhIEycfo.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
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
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
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 pgpAQ5zLeQLu1.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
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 pgpNIXaqU338V.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
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
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 pgpjGqTBJKirx.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
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/
