Hi, On 2016-09-04 19:09, Rob Browning wrote: > Aurelien Jarno <aure...@debian.org> writes: > > > Ok, great if you are working on a release. I am not on a hurry > > personally, the package in the archive still works perfectly, the > > problem is just when trying to rebuild it. Given I am the "one" who > > broke that, I felt that I have to offer help. > > I've started looking at the changes, and normally, when possible, I like > to cherry pick from the upstream changes (say from emacs-25), and it > looked like this commit might cover the the gmalloc patch (after > resolving a minor merge conflict): > > commit 4b1436b702d56eedd27a0777fc7232cdfb7ac4f6 > Author: Wolfgang Jenkner <wjenk...@inode.at> > Date: Sat Dec 26 12:12:02 2015 -0800 > > Always define gmalloc etc. in src/gmalloc.c > > This is a work-around to prevent the compiler from using semantic > knowledge about malloc for optimization purposes. E.g., gcc 5.2 > with -O2 replaces most of calloc's definition by a call to calloc; > see Bug#22085. > * src/gmalloc.c [!HYBRID_MALLOC] (malloc, realloc, calloc) > (aligned_alloc, free): Do not undef. Instead, define these as > functions (perhaps renamed to gmalloc etc.) in terms of gmalloc etc. > > But I didn't find anything as directly relevant for the glibc patch. > Perhaps there's nothing very close upstream (with respect to emacs-24), > i.e. maybe the patch you've attached is more appropriate there?
The patch i have attached is actually a backport of the above patch. It was present in various branches, so I might have backported one with a different commit number, but in practice it's the same. The other patch I attached is also backported from upstream. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
