Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

[Dongsheng S. <don...@gm...>]

于 2010-7-28 16:02, Kai Tietz 写道:
> 2010/7/28 Dongsheng Song <don...@gm...>:
>> 于 2010-7-28 15:43, Kai Tietz 写道:
>>> 2010/7/28 Dongsheng Song <don...@gm...>:
>>>> Hi Kai,
>>>>
>>>> When we cross build gcc 4.5 for windows, I found we can build windows gcc binary one
>>>> week ago, but now the build failed.
>>>>
>>>> After I do a binary search, I found the issue caused by r2945.
>>>>
>>>>    r2950 | 2010-07-24 05:50:28 | FAILED
>>>>    r2945 | 2010-07-24 02:44:15 | FAILED
>>>>    r2944 | 2010-07-24 02:38:30 | SUCCESS
>>>>    r2939 | 2010-07-23 17:55:30 | SUCCESS
>>>>    r2928 | 2010-07-23 05:21:20 | SUCCESS
>>>>    r2924 | 2010-07-22 18:32:25 | SUCCESS
>>>>
>>>> r2945 remove some *IMPORTANT* macros from /trunk/mingw-w64-headers/crt/float.h,
>>>> e.g. FLT/DBL/LDBL_MANT_DIG, FLT_EVAL_METHOD, *ALL* decimal macros (DEC32/64/128_*, ...)
>>>>
>>>> When I add FLT/DBL/LDBL_MANT_DIG and FLT_EVAL_METHOD back to /trunk/mingw-w64-headers/crt/float.h,
>>>> then the gcc cross build success again.
>>>>
>>>> So I recommend you apply the attached patch at least.
>>>>
>>>> btw, I know FLT_EVAL_METHOD added by C99, but libgfortran/m4/nearest.m4 use it,
>>>> is it mean we should use ISO C99 compiler to build gcc 4.5 or later, not ISO C90 as
>>>> http://gcc.gnu.org/install/prerequisites.html ?
>>>>
>>>> Regards,
>>>> Dongsheng
>>>
>>> Hello Dongsheng,
>>>
>>> the recent change to float.h was necessary to support the new
>>> include_next patch of 4.6. So how are you exactly installing headers?
>>> As usual you should just see gcc's internal float.h for older gcc's
>>> then 4.6. So I am a bit puzzled. Are you removing gcc's float.h here?
>>>
>>> Regards,
>>> Kai
>>>
>>
>> Hi Kai,
>>
>> I use Debian 6.0 i686 with latest update, gcc 4.4.4 build a gcc 4.5 cross compiler for windows,
>> then use the cross compiler to build a native gcc 4.5 compiler for windows.
>>
>> Without the patch, both i686-windows and x64-windows failed during build native
>> compiler.
>>
>> It's strange since I can build cross compiler, it maybe a gcc bug.
>>
>> The related packages is:
>> gcc 4.5 branch, mingw64 trunk, binutils trunk, gmp 5.0 branch, mpfr 3.0 branch,
>> mpc 0.8.2, ppl 0.10.2, cloog-ppl 0.15.9.
>>
>> Regards,
>> Dongsheng
>>
>>
> 
> Well, yes it is a gcc bug in respect to native/cross toolchains. I
> assume that your search path installs headers (and libraries) in
> standard_include for native. This cause that the system-headers get
> included before fixed-include and gcc-include.
> For this I can provide a patch. See revision 2986. But indeed this
> include-order of gcc is a conceptional flaw.
> 
> Cheers,
> Kai
> 

This build error fixed now, thank your excellent work !

Thank you very much !

But new error occurred when I use cross compiler to build native compiler:

...
i686-w64-mingw32-gcc  -O2 -pipe -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat
-DHAVE_CONFIG_H -s -o f951.exe \
		fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o fortran/cpp.o fortran/data.o fortran/decl.o fortran/dump-parse-tree.o
fortran/error.o fortran/expr.o fortran/interface.o fortran/intrinsic.o fortran/io.o fortran/iresolve.o fortran/match.o fortran/matchexp.o
fortran/misc.o fortran/module.o fortran/openmp.o fortran/options.o fortran/parse.o fortran/primary.o fortran/resolve.o fortran/scanner.o
fortran/simplify.o fortran/st.o fortran/symbol.o fortran/target-memory.o  fortran/convert.o fortran/dependency.o fortran/f95-lang.o
fortran/trans.o fortran/trans-array.o fortran/trans-common.o fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o
fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o fortran/trans-stmt.o fortran/trans-types.o main.o  libbackend.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  attribs.o
-L/home/oracle/gcc-4.5-w32_i686-linux/lib -lcloog -L/home/oracle/gcc-4.5-w32_i686-linux/lib -lppl_c -lppl -lgmpxx -L/home/oracle/gcc-4.5-w32/lib
-L/home/oracle/gcc-4.5-w32/lib -L/home/oracle/gcc-4.5-w32/lib -lmpc -lmpfr -lgmp   -L../zlib -lz
/home/oracle/gcc-4.5-w32_i686-linux/lib/libppl_c.a(ppl_c_implementation_common.o): In function `__tcf_0':

...

/home/oracle/gcc-4.5-w32/lib/libgmpxx.a(isfuns.o):isfuns.cc:(.text+0x2be): undefined reference to `std::ios_base::Init::Init()'
collect2: ld returned 1 exit status
make[2]: *** [cc1plus-dummy.exe] Error 1
rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gcc.pod gfortran.pod
make[2]: Leaving directory `/home/oracle/tmp/gcc-4.5-w32-obj/gcc/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/oracle/tmp/gcc-4.5-w32-obj/gcc'
make: *** [all] Error 2

Then I run:

sed -i "s/-lgmpxx/-lgmpxx -lstdc++/g" ${NATIVE_OBJ_ROOT}/gcc/gcc/Makefile
make all

So I can build smoothly.

Is this a known bug ?

Regards,
Dongsheng