emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Trunk bootstrap failure [Cygwin]


From: Dan Nicolaescu
Subject: Re: Trunk bootstrap failure [Cygwin]
Date: Wed, 07 Jul 2010 12:22:36 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

Angelo Graziosi <address@hidden> writes:

> Il 06/07/2010 17.19, Dan Nicolaescu ha scritto:
>> Angelo Graziosi<address@hidden>  writes:
>>
>>> Il 06/07/2010 4.29, Dan Nicolaescu ha scritto:
>>>> Angelo Graziosi<address@hidden>   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
> +

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]