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.3r2=1.4cvsroot=srcf=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.2content-type=text/x-cvsweb-markupcvsroot=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/
