i686-pc-cygwin crash gcc-4.0 branch

[Bobby McNulty]

Brian Dessent wrote:
> Brian Dessent wrote:
> 
> 
>>>/home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/
>>>-B/usr/local/i686-pc-c
>>>ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
>>>/usr/local/i686-pc-cygwin/i
>>>nclude -isystem /usr/local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H
>>>-I. -I../.
>>>./../../gcc-4_0-branch/libstdc++-v3/libmath -I.. -O2 -g -O2 -c
>>>../../../../gcc-4
>>>_0-branch/libstdc++-v3/libmath/signbit.c -o signbit.o
>>>In file included from
>>>../../../../gcc-4_0-branch/libstdc++-v3/libmath/signbit.c:
>>>32:
>>>../../../../gcc-4_0-branch/libstdc++-v3/libmath/mathconf.h:167: error:
>>>conflicti
>>>ng types for 'ieee_double_shape_type'
>>
>>It looks like what is happening is BYTE_ORDER isn't getting defined
>>correctly.  This is supposed to be taken care of by the sys/param.h
>>header of the target, which Cygwin does provide correctly.  It looks
>>like for some reason gcc isn't picking this up in your case.  Are you
>>doing a native or a cross?  What configure options are you using?
> 
> 
> This is caused by this change:
> <http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/endian.h.diff?r1=1.3&r2=1.4&cvsroot=src&f=h>. 
> This modified include/endian.h to only conditionally define BYTE_ORDER
> etc. if __USE_BSD is defined, whereas before in newlib's
> machine/endian.h
> <http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/newlib/libc/include/machine/endian.h?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=src>
> they were defined unconditionally.
> 
> Thus if you build gcc with the 1.5.18 version of cygwin and its headers
> you don't run into this, but if you try to use a snapshot that contains
> this change you get the above error.
> 
> Brian
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 
> 
> 
I nuked my cygwin, and started over again.
Used svn to get the trunk of gcc.
I have a snapshot gcc 4.0, but I am not building it.
Anyway, compiling just with the 1.5.18 cygwin dll solved.
Since this is just staying on the cutting edge of programming, I am only 
going to use release cygwin1.dll.
Waiting for cygwin 1.5.19
Bobby.
It worked. trunk is able to compile again in Cygwin.




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/