[Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros
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 Index: mingw-w64-headers/crt/float.h === --- mingw-w64-headers/crt/float.h (revision 2984) +++ mingw-w64-headers/crt/float.h (working copy) @@ -31,6 +31,33 @@ #define_MCW_RC 0x0300 /* Rounding */ #define_MCW_PC 0x0003 /* Precision */ +/* Number of base-FLT_RADIX digits in the significand, p. */ +#undef FLT_MANT_DIG +#undef DBL_MANT_DIG +#undef LDBL_MANT_DIG +#define FLT_MANT_DIG __FLT_MANT_DIG__ +#define DBL_MANT_DIG __DBL_MANT_DIG__ +#define LDBL_MANT_DIG __LDBL_MANT_DIG__ + +#if defined (__STDC_VERSION__) __STDC_VERSION__ = 199901L +/* The floating-point expression evaluation method. +-1 indeterminate + 0 evaluate all operations and constants just to the range and +precision of the type + 1 evaluate operations and constants of type float and double +to the range and precision of the double type, evaluate +long double operations and constants to the range and +precision of the long double type + 2 evaluate all operations and constants to the range and +precision of the long double type + + ??? This ought to change with the setting of the fp control word; + the value provided by the compiler assumes the widest setting. */ +#undef FLT_EVAL_METHOD +#define FLT_EVAL_METHOD__FLT_EVAL_METHOD__ + +#endif /* C99 */ + /* Control word values for unNew (use with related unMask above) */ #define_DN_SAVE0x #define_DN_FLUSH 0x0100 signature.asc Description: OpenPGP digital signature -- 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://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros
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 -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- 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://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros
On Wed, Jul 28, 2010 at 10:54 AM, Dongsheng Song dongsheng.s...@gmail.com wrote: 于 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. You cannot build 4.4/4.5 based compilers against the mingw-w64-headers from the trunk unless you patch your gcc according to gcc PR/41943 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 -- Ozkan -- 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://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros
2010/7/28 Ozkan Sezer seze...@gmail.com: On Wed, Jul 28, 2010 at 10:54 AM, Dongsheng Song dongsheng.s...@gmail.com wrote: 于 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. You cannot build 4.4/4.5 based compilers against the mingw-w64-headers from the trunk unless you patch your gcc according to gcc PR/41943 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 -- Ozkan The problematic thing here is, that for cross-compiler and native different include dependencies are there. So it is absolutely unpredicatable (for now), if toolchain's header are used in native (so the float.h/stddef.h etc are seen first from system-headers), or if it is by a cross-toolchain, which has in front the gcc-internal header versions of those files. All in all it is simply a mess. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- 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://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros
于 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
signature.asc
Description: OpenPGP digital signature
--
The Palm
Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros
On 7/28/2010 20:32, Dongsheng Song wrote:
于 2010-7-28 16:02, Kai Tietz 写道:
2010/7/28 Dongsheng Songdongsheng.s...@gmail.com:
于 2010-7-28 15:43, Kai Tietz 写道:
2010/7/28 Dongsheng Songdongsheng.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
Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?
On Wed, Jul 28, 2010 at 9:44 AM, Earnie ear...@users.sourceforge.net wrote: JonY wrote: MSYS has been strongly associated with mingw.org for a very long time, hence to autotools, MSYS uname string can be assumed to be i686-pc-mingw32. Hello JonY and Ernie, Thank you both for your responses. Let me state that the string from the MSYS uname is controlled by an environment variable MSYSTEM. So if MSYSTEM is changed to say mingw64 then the config.guess and config.sub scripts could be changed to recognize the uname string to produce i686-pc-mingw64, x86_64-mingw64 or even x86_64-w64-mingw32 which ever is preferred. The uname string from MSYS would read MINGW64_NT-5.1 if MSYSTEM=mingw64. I believe MSYSTEM should be set uppercase, as setting mingw32 lowercase do not identify properly. This change should be send upstream? My personal preference for a config.guess return string would be x86_64-w64-mingw. I believe this was already established as x86_64-w64-mingw32 ? http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry -- 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
Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?
environment variable MSYSTEM. So if MSYSTEM is changed to say mingw64 then the config.guess and config.sub scripts could be changed to recognize the uname string to produce i686-pc-mingw64, x86_64-mingw64 or even x86_64-w64-mingw32 which ever is preferred. The uname string from MSYS would read MINGW64_NT-5.1 if MSYSTEM=mingw64. I believe MSYSTEM should be set uppercase, as setting mingw32 lowercase do not identify properly. This change should be send upstream? My personal preference for a config.guess return string would be x86_64-w64-mingw. I believe this was already established as x86_64-w64-mingw32 ? http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS Great, someone actually found the wiki! MSYS itself is 32-bit, so having uname return something else is not quite correct. There are other things bad about this suggestion: 1. What if you have installed x86_64-w64-mingw32-gcc, i686-w64-mingw32-gcc, and i686-pc-mingw32-gcc, and added all three paths to MSYS's path? uname isn't at all a correct way to determine the compiler's target, especially when you think about cross-compilation, and (future/current) multilib. 2. The wiki states the workaround/The Right Way to use mingw-w64 under MSYS. I believe passing -host=... to configure is a small price to pay (if any) for the functionality you get from using MSYS+mingw-w64. The MSYS package provided by mingw-w64 (aka me in this context) is only the complete binary set of packages conveniently packed into one. I don't feel I have the right/will to change internal settings (of which I do not know how far these reach) or to keep any changes up to date. I hope you can understand my reasoning, and I'll be happy to read any arguments against what I stated above and consider revising my opinion, but MSYS works fine as is. Ruben -- 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
Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?
Ruben Van Boxem wrote: http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS Great, someone actually found the wiki! MSYS itself is 32-bit, so having uname return something else is not quite correct. There are other things bad about this suggestion: 1. What if you have installed x86_64-w64-mingw32-gcc, i686-w64-mingw32-gcc, and i686-pc-mingw32-gcc, and added all three paths to MSYS's path? uname isn't at all a correct way to determine the compiler's target, especially when you think about cross-compilation, and (future/current) multilib. 2. The wiki states the workaround/The Right Way to use mingw-w64 under MSYS. While MSYS is currently only offered as a 32bit application, you are using it in a 64bit system to do 64bit work. So you want your build environment to reflect natively that you are in a 64bit system. The resolution to what if I have this GCC build and that GCC build is no different than what you need to do now for multiple versions of the product. You just create a script to modify the PATH to point to the correct GCC build. I believe passing -host=... to configure is a small price to pay (if any) for the functionality you get from using MSYS+mingw-w64. The MSYS package provided by mingw-w64 (aka me in this context) is only the complete binary set of packages conveniently packed into one. Not really a big thing, just comfortableness of the end user. I don't feel I have the right/will to change internal settings (of which I do not know how far these reach) or to keep any changes up to date. I can create a patch to the msys.bat file that would allow the MSYSTEM to be set to MINGW64 just by passing in a parameter of MINGW64. Currently though if the environment variable is set before starting MSYS it will use that value. So if you start your MSYS with MSYSTEM=MINGW32 and then do ``MSYSTEM=MINGW64 start /msys.bat'' it will open a new window with a build environment for MINGW64. I hope you can understand my reasoning, and I'll be happy to read any arguments against what I stated above and consider revising my opinion, but MSYS works fine as is. I understand your reasoning do you understand mine? My reasoning is toward the comfortableness of the noob who just wants to build 64bit native binaries with the least amount of typing. I am sure that MSYS works fine as you have documented it. But I did create the beast and MSYSTEM was meant to be used to control the build environment so that config.guess could guess correctly. I just didn't get around to documenting it formally. Earnie -- 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
Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?
On Wed, Jul 28, 2010 at 1:39 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: MSYS itself is 32-bit, so having uname return something else is not quite correct. There are other things bad about this suggestion: 1. What if you have installed x86_64-w64-mingw32-gcc, i686-w64-mingw32-gcc, and i686-pc-mingw32-gcc, and added all three paths to MSYS's path? uname isn't at all a correct way to determine the compiler's target, especially when you think about cross-compilation, and (future/current) multilib. 2. The wiki states the workaround/The Right Way to use mingw-w64 under MSYS. I believe passing -host=... to configure is a small price to pay (if any) for the functionality you get from using MSYS+mingw-w64. The MSYS package provided by mingw-w64 (aka me in this context) is only the complete binary set of packages conveniently packed into one. I don't feel I have the right/will to change internal settings (of which I do not know how far these reach) or to keep any changes up to date. While I understand the small price to pay, I'm working on a tool that build recipes for the different compilers, and uses sh -c ./config.guess to determine the platform for it's own use. It allow the user to use a configuration setting to override it, but ideally the compilers should be transparent to the tool. If this can't be worked out, we will need to fall back to lookup for *gcc* in the path and extrapolate the platform from it or the compilation of a simple .C file Thank you guys for your answers. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry -- 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
