From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: Trunk bootstrap failure [Cygwin] Date: Wed, 07 Jul 2010 12:22:36 -0400 Message-ID: References: <4C326C4F.2010604@alice.it> <4C32F295.7050608@alice.it> <4C344500.9010906@alice.it> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1278519772 3689 80.91.229.12 (7 Jul 2010 16:22:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 7 Jul 2010 16:22:52 +0000 (UTC) Cc: Eli Zaretskii , Ken Brown , emacs To: Angelo Graziosi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 07 18:22:50 2010 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.69) (envelope-from ) id 1OWXOa-0002kB-6N for ged-emacs-devel@m.gmane.org; Wed, 07 Jul 2010 18:22:49 +0200 Original-Received: from localhost ([127.0.0.1]:43759 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OWXOW-0006oQ-KM for ged-emacs-devel@m.gmane.org; Wed, 07 Jul 2010 12:22:44 -0400 Original-Received: from [199.232.76.173] (port=41901 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OWXOR-0006o9-5g for emacs-devel@gnu.org; Wed, 07 Jul 2010 12:22:39 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1OWXOP-0001gB-I9 for emacs-devel@gnu.org; Wed, 07 Jul 2010 12:22:39 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:46130) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1OWXOP-0001g7-9P for emacs-devel@gnu.org; Wed, 07 Jul 2010 12:22:37 -0400 Original-Received: from dann by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1OWXOO-00056Q-8I; Wed, 07 Jul 2010 12:22:36 -0400 In-Reply-To: <4C344500.9010906@alice.it> (Angelo Graziosi's message of "Wed\, 07 Jul 2010 11\:12\:32 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:126876 Archived-At: Angelo Graziosi writes: > Il 06/07/2010 17.19, Dan Nicolaescu ha scritto: >> Angelo Graziosi writes: >> >>> Il 06/07/2010 4.29, Dan Nicolaescu ha scritto: >>>> Angelo Graziosi writes: >>>> >>>>> Current trunk (rev. 100729) fails to bootstrap on Cygwin in this way: >>>>> >>>>> [...] >>>>> gcc -c -Demacs -DHAVE_CONFIG_H -I. -I/tmp/emacs/src -D_REENTRANT >>>>> -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include >>>>> -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 >>>>> -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 >>>>> -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 >>>>> -I/usr/include/freetype2 -I/usr/include/libpng12 >>>>> -I/usr/include/freetype2 -D_REENTRANT -I/usr/include/librsvg-2 >>>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include >>>>> -I/usr/include/gtk-2.0 -I/usr/include/cairo -I/usr/include/pixman-1 >>>>> -I/usr/include/freetype2 -I/usr/include/libpng12 >>>>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -DORBIT2=3D1 >>>>> -D_REENTRANT -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 >>>>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include >>>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 >>>>> -Wdeclaration-after-statement -Wno-pointer-sign -MMD -MF >>>>> deps/ecrt0.d /tmp/emacs/src/ecrt0.c >>>>> /tmp/emacs/src/ecrt0.c: In function =E2=80=98_start=E2=80=99: >>>>> /tmp/emacs/src/ecrt0.c:74: error: too few arguments to function =E2= =80=98start1=E2=80=99 >>>>> make[2]: *** [ecrt0.o] Error 1 >>>>> make[2]: Leaving directory `/tmp/emacs/build/src' >>>>> make[1]: *** [src] Error 2 >>>>> make[1]: Leaving directory `/tmp/emacs/build' >>>>> make: *** [bootstrap] Error 2 >>>>> >>>>> The bootstrap I did on 01 July (rev. 100669) was fine. >>>> >>>> I reverted the conversion to standard C for ecrt0.c, it should be fine= now. >>>> cygwin is the only user for ecrt0.c >>>> Can you please experiment changing >>>> START_FILES=3D'ecrt0.o' >>>> to either: >>>> START_FILES=3D'pre-crt0.o' >>>> or >>>> START_FILES=3D >>>> in emacs/configure >>>> and see if any of those work? >>> >>> Both solutions, you suggest, fail. >> >> Thanks. Oh, well, someone would have to look at the details of the >> cygwin build to figure out if this can be really done... > > Hmm... I have seen that on Cygwin: > > $ objdump.exe -p foo.exe | fgrep ImageBase > > returns always: > > ImageBase 00400000 > > I have seen also that there are, in Emacs source tree, other systems > (see src/s/mips.h, for example) which define 'TEXT_START 0x00400000'. > > So, not knowing how 'to read or write', I have applied these > self-explanatory patches... > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- configure.orig 2010-07-02 11:27:38.000000000 +0200 > +++ configure 2010-07-06 10:45:21.656250000 +0200 > @@ -5864,7 +5864,7 @@ > case $opsys in > cygwin ) > LIB_MATH=3D > - START_FILES=3D'ecrt0.o' > + START_FILES=3D'pre-crt0.o' > ;; > darwin ) > ## Adding -lm confuses the dynamic linker, so omit it. > --- cygwin.h.orig 2010-06-06 11:34:28.000000000 +0200 > +++ cygwin.h 2010-07-07 10:24:22.625000000 +0200 > @@ -112,5 +112,7 @@ > returns ENOSYS. A workaround is to set G_SLICE=3Dalways-malloc. */ > #define G_SLICE_ALWAYS_MALLOC > > +#define TEXT_START 0x00400000 > + It looks like the start_of_text function is only used on AIX and MSDOS, so you can get the same result by completely removing start_of_text,= which makes the=20 #define TEXT_START unnecessary. I'll add the needed conditionals around start_of_text soon. > ...and Emacs (rev. 100739) bootstraps fine... > > But, are those patches the best solution? Are we sure that in the > future there will not pitfalls or drawbacks? IMHO if you can run a few days without problems, it should be fine, this should generate memory problems pretty fast if it's wrong... > > Eli, Ken, have you comments and/or suggestions? > > Thanks, > Angelo.