From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22560 invoked by alias); 13 Aug 2013 14:13:12 -0000 Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com Received: (qmail 22550 invoked by uid 89); 13 Aug 2013 14:13:12 -0000 X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 Received: from limerock02.mail.cornell.edu (HELO limerock02.mail.cornell.edu) (128.84.12.100) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 13 Aug 2013 14:13:11 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock02.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id r7DED8So027221 for ; Tue, 13 Aug 2013 10:13:09 -0400 Received: from [192.168.1.4] (cpe-67-249-194-47.twcny.res.rr.com [67.249.194.47]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id r7DED7gH010843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 13 Aug 2013 10:13:08 -0400 Message-ID: <520A3EF6.80700@cornell.edu> Date: Tue, 13 Aug 2013 14:13:00 -0000 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: cygwin-xfree@cygwin.com Subject: Re: [ANNOUNCEMENT] Uploads for 12 August References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> In-Reply-To: <520A21B1.8060503@alice.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00019.txt.bz2 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/