On 7/30/2010 09:50, Dongsheng Song wrote: > On Wed, Jul 28, 2010 at 21:42, JonY<jo...@users.sourceforge.net> wrote: >> On 7/28/2010 20:32, Dongsheng Song wrote: >>> >>> 于 2010-7-28 16:02, Kai Tietz 写道: >>>> >>>> 2010/7/28 Dongsheng Song<dongsheng.s...@gmail.com>: >>>>> >>>>> 于 2010-7-28 15:43, Kai Tietz 写道: >>>>>> >>>>>> 2010/7/28 Dongsheng Song<dongsheng.s...@gmail.com>: >>>>>>> >>>>>>> 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 >>> >> >> Use g++ to link? g++ auto adds those libraries to the list of archives to >> link. >> > > I do not understand what your mean, link command generated by GCC > build script, not by me. >
Hi, sorry, I thought you were linking a self built program. You need to use "--with-host-libstdcxx=-lstdc++", this is needed by gmpxx and ppl. ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
