Re: Trunk bootstrap failure [Cygwin]

[Angelo Graziosi <angelo.graziosi@alice.it>]

Il 06/07/2010 17.19, Dan Nicolaescu ha scritto:
> Angelo Graziosi<angelo.graziosi@alice.it>  writes:
>
>> Il 06/07/2010 4.29, Dan Nicolaescu ha scritto:
>>> Angelo Graziosi<angelo.graziosi@alice.it>   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=1
>>>> -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 ‘_start’:
>>>> /tmp/emacs/src/ecrt0.c:74: error: too few arguments to function ‘start1’
>>>> 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='ecrt0.o'
>>> to either:
>>> START_FILES='pre-crt0.o'
>>> or
>>> START_FILES=
>>> 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...

============
--- 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=
-    START_FILES='ecrt0.o'
+    START_FILES='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=always-malloc. */
  #define G_SLICE_ALWAYS_MALLOC

+#define TEXT_START      0x00400000
+
  /* arch-tag: 5ae7ba00-83b0-4ab3-806a-3e845779191b
     (do not change this comment) */
============

...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?

Eli, Ken, have you comments and/or suggestions?

Thanks,
Angelo.