From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Warning starting Emacs (Cygwin) Date: Sat, 02 Aug 2008 22:54:21 +0300 Message-ID: References: <4891D01B.6070802@alice.it> <4891E7E8.1000503@alice.it> <200807311700.m6VH0eCa004994@sallyv1.ics.uci.edu> <4892E7BE.1080706@alice.it> <489306EE.7090800@alice.it> <200808011308.m71D8PA3023871@sallyv1.ics.uci.edu> <489319F7.5040101@alice.it> <200808011436.m71EaAeZ019293@sallyv1.ics.uci.edu> <4893765E.5020803@alice.it> <200808020406.m7246D1T003058@sallyv1.ics.uci.edu> <48946F36.3020505@alice.it> <200808021859.m72IxGnr000877@sallyv1.ics.uci.edu> <87wsiz1b6l.fsf@stupidchicken.com> <200808021930.m72JUTrw014872@sallyv1.ics.uci.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1217706878 6175 80.91.229.12 (2 Aug 2008 19:54:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Aug 2008 19:54:38 +0000 (UTC) Cc: cyd@stupidchicken.com, angelo.graziosi@alice.it, emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 02 21:55:28 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KPNCJ-0003C7-Ca for ged-emacs-devel@m.gmane.org; Sat, 02 Aug 2008 21:55:27 +0200 Original-Received: from localhost ([127.0.0.1]:34052 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KPNBO-0003B1-LV for ged-emacs-devel@m.gmane.org; Sat, 02 Aug 2008 15:54:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KPNBK-00038N-6L for emacs-devel@gnu.org; Sat, 02 Aug 2008 15:54:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KPNBJ-000375-B0 for emacs-devel@gnu.org; Sat, 02 Aug 2008 15:54:25 -0400 Original-Received: from [199.232.76.173] (port=45788 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KPNBI-00036r-Ux for emacs-devel@gnu.org; Sat, 02 Aug 2008 15:54:25 -0400 Original-Received: from mtaout7.012.net.il ([84.95.2.19]:50210) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KPNBI-0007Vq-H4 for emacs-devel@gnu.org; Sat, 02 Aug 2008 15:54:24 -0400 Original-Received: from HOME-C4E4A596F7 ([84.229.228.238]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K4Z008HZOMTA340@i-mtaout7.012.net.il> for emacs-devel@gnu.org; Sat, 02 Aug 2008 22:54:30 +0300 (IDT) In-reply-to: <200808021930.m72JUTrw014872@sallyv1.ics.uci.edu> X-012-Sender: halo1@inter.net.il X-detected-kernel: by monty-python.gnu.org: Solaris 10 (1203?) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:101970 Archived-At: > From: Dan Nicolaescu > Date: Sat, 02 Aug 2008 12:30:29 -0700 > Cc: emacs-devel@gnu.org, Angelo Graziosi > > Chong Yidong writes: > > > Dan Nicolaescu writes: > > > > > Unfortunately none of these ring a bell to me. Yidong I assume this > > > code is the reason you added the HAVE_GETRLIMIT autoconf check, can you > > > guess what can be wrong here? > > > > The reason I added the getrlimit check was because of the bug reported > > here (bug#86): > > The check is very likely fine, I was hoping you understand the code the > macro guards... Please see Angelo's messages, he gives a lot of details > that might ring a bell. It's quite clear from what Angelo wrote that Cygwin's getrlimit is not a fully functional emulation. Just to be sure, I looked into the Cygwin sources and found this gem: extern "C" int getrlimit (int resource, struct rlimit *rlp) { [...] switch (resource) { [...] case RLIMIT_AS: rlp->rlim_cur = 0x80000000UL; rlp->rlim_max = 0x80000000UL; break; This obviously cannot work with vm-limit.c. I think the test in configure should compare rlim_cur with rlim_max, and if they are identical, deduce that getrlimit is non-functional and not set HAVE_GETRLIMIT.