From: JonY <10...@gm...> - 2009-08-25 01:57:13
|
<< Starting New Thread >> On 8/25/2009 07:53, Sisyphus wrote: >> You can build 2.4.x it from source, grab it at <http://www.mpfr.org/>. > > Yes, I already have the source. I guess I could use the provided gmp > binaries to build mpfr, but I would prefer to use a gmp I had built myself. > Also, building my own gmp would enable me to use gmp-4.3.1. > (In any case, I expect the issues I'm facing in trying to build gmp would > still be a stumbling block when it comes to building mpfr.) > >> Did you remember to pass --build/--host to configure? > > No, I didn't. How do I determine the correct values for --build and --host ? > Hi, Here is what the machine triplet, build, host, and target option does: * machine triplet - The triplet key identifies a platform. Usually comes in the form of "cpu"-"vendor"-"system". * build - Build machine triplet, usually corresponds with native gcc target (gcc -dumpmachine). In this case it is "i686-pc-mingw32". * host - The platform in which you want the library/program you just compiled to run on. You need a cross compiler to this (the mingw-w64 toolchain targeting win64 from sf is a cross compiler). Since you want them to run on win64, it is "x86_64-w64-mingw32". * target - This option is usually unused. It is reserved for compilers, assemblers, or other code generators. It specifies the platform the code generator will produce code for. The toolchain in mingw-w64-bin_i686-mingw_20090819.zip is very old, it uses the "pc" vendor key instead of "w64". I suggest you use one of the automated toolchain builds targeting win64. There has been a lot of bug fixes and feature enhancements since then. If you are trying to rebuild GCC, you can place gmp and mpfr at the root of the GCC source tree as "gmp" and "mpfr" respectively. GCC will pass the correct options to it. If you want them installed as libraries, you should pass "--build=i686-pc-mingw32 --host=x86_64-w64-mingw32" to configure. configure assumes you want a native build if those aren't specified. The configure script from GMP is a bit different, it checks the cpu key to enable assembly optimizations. Due to the different ABI for Linux and win64, it doesn't work yet. Pass "--host=none-none-none CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ AR=x86_64-w64-mingw32-ar LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm RANLIB=x86_64-w64-mingw32-ranlib ABI=longlong" to build it without assembly optimization. For MPFR, passing just the --build/--host option should work fine. HTH |
From: <sis...@op...> - 2009-08-26 13:19:42
|
> JonY <10...@gm...> wrote: > > This a little more serious - those references are, indeed, not defined > > in libmpc.a. This smells to me like a bug in mpc itself. (Again, I'll > > have to take a closer look when time permits.) > > > > Hi, > this looks like a real problem, I haven't encountered it before. > > I'll investigate further once I get the time; or until xeno shows up on > irc, he's been doing trying to make a win64 toolchain too. I'm sure he > has something to say. I hacked my way past this problem as follows: In both src/set_x.c and src/set_x_x.c I changed: #if HAVE_INTTYPES_H to #if 1 and I changed #ifdef _MPC_H_HAVE_INTMAX_T to #if 1 Then ran 'make distclean' and started afresh. All was then fine, and all tests built and passed. It seems that, somehow, HAVE_INTTYPES_H is untrue and _MPC_H_HAVE_INTMAX_T is undefined at the 'make' stage, but HAVE_INTTYPES_H is true and _MPC_H_HAVE_INTMAX_T is defined during the 'make check' stage. I figured (perhaps incorrectly) that this was a problem with the mpc source, and posted to the mpc-discuss mailing list. My post there still awaits moderator approval as the post is just over their allowable 40kb in size. (I think it's the config.log which I sent as an attachment with that post that's providing most of that 40kb.) Cheers, Rob |
From: JonY <10...@gm...> - 2009-08-26 13:57:26
|
On 8/26/2009 21:19, sis...@op... wrote: > > I hacked my way past this problem as follows: > > In both src/set_x.c and src/set_x_x.c I changed: > > #if HAVE_INTTYPES_H > to > #if 1 > > and I changed > > #ifdef _MPC_H_HAVE_INTMAX_T > to > #if 1 > > Then ran 'make distclean' and started afresh. All was then fine, and all tests built and passed. > > It seems that, somehow, HAVE_INTTYPES_H is untrue and _MPC_H_HAVE_INTMAX_T is undefined at the 'make' stage, but HAVE_INTTYPES_H is true and _MPC_H_HAVE_INTMAX_T is defined during the 'make check' stage. > > I figured (perhaps incorrectly) that this was a problem with the mpc source, and posted to the mpc-discuss mailing list. My post there still awaits moderator approval as the post is just over their allowable 40kb in size. (I think it's the config.log which I sent as an attachment with that post that's providing most of that 40kb.) > Hi, The logs might show something interesting. you can use gzip or bzip2 to compress the config.log file or post it at pastebin.com. |
From: Sisyphus <sis...@op...> - 2009-08-26 18:46:26
Attachments:
config.log.gz
|
----- Original Message ----- From: "JonY" <10...@gm...> > > Hi, > > The logs might show something interesting. > > you can use gzip or bzip2 to compress the config.log file or post it at > pastebin.com. Hi JonY, config.log.gz is attached. Cheers, Rob |
From: JonY <10...@gm...> - 2009-08-26 23:50:59
|
On 8/27/2009 02:44, Sisyphus wrote: > > Hi JonY, > > config.log.gz is attached. > Hi, strangely, at the end of the config.log, I find at the end of config.log: #define HAVE_INTTYPES_H 1 Maybe some file wasn't including config.h right, or erroneously using pthreads config.h. |
From: Sisyphus <sis...@op...> - 2009-08-27 03:01:24
|
----- Original Message ----- From: "JonY" <10...@gm...> To: <min...@li...> Sent: Thursday, August 27, 2009 9:37 AM Subject: Re: [Mingw-w64-public] mingw-w64 builds of gmp and mpfr > On 8/27/2009 02:44, Sisyphus wrote: >> >> Hi JonY, >> >> config.log.gz is attached. >> > > Hi, > strangely, at the end of the config.log, I find at the end of config.log: > #define HAVE_INTTYPES_H 1 > > Maybe some file wasn't including config.h right, or erroneously using > pthreads config.h. Well ... I've just unpacked the mpc-0.6 source tarball again, and it now builds fine. Apparently, I must have made some change to the mpc-0.6 source that I had originally unpacked - and that change was stuffing things up for the 64-bit build (but not the 32-bit build). Sorry for the noise and please ignore. Cheers, Rob |
From: Sisyphus <sis...@op...> - 2009-08-25 05:02:47
|
----- Original Message ----- From: "JonY" <10...@gm...> > Pass "--host=none-none-none CC=x86_64-w64-mingw32-gcc > CXX=x86_64-w64-mingw32-g++ AR=x86_64-w64-mingw32-ar > LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm > RANLIB=x86_64-w64-mingw32-ranlib ABI=longlong" to build it without > assembly optimization. Excellent - many thanks for providing that, JonY. This is great !! GMP builds fine, and the tests all pass until we get to the tests/misc tests where we apparently come up against a redefinition of 'localeconv': #################################### x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../tests -DNO_ASM -O2 -pedantic -c t-locale.c In file included from t-locale.c:40:0: ../../gmp.h:191:23: warning: ISO C90 does not support 'long long' ../../gmp.h:192:14: warning: ISO C90 does not support 'long long' t-locale.c:50:1: warning: 'localeconv' redeclared without dllimport attribute: previous dllimport ignored /bin/sh ../../libtool --mode=link x86_64-w64-mingw32-gcc -O2 -pedantic -o t-locale.exe t-locale.o ../../tests/libtests.la ../../libgmp.la x86_64-w64-mingw32-gcc -O2 -pedantic -o t-locale.exe t-locale.o ../../tests/.libs/libtests.a /c/_32/comp/gmp-4.3.1/.libs/libgmp.a ../../.libs/libgmp.a c:/_64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/libmsvcrt.a(dslcs00660.o):(.text+0x0): multiple definition of `localeconv' t-locale.o:t-locale.c:(.text+0x0): first defined here collect2: ld returned 1 exit status make[4]: *** [t-locale.exe] Error 1 make[4]: Leaving directory `/c/_32/comp/gmp-4.3.1/tests/misc' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/c/_32/comp/gmp-4.3.1/tests/misc' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/c/_32/comp/gmp-4.3.1/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/c/_32/comp/gmp-4.3.1' make: *** [check] Error 2 #################################### Any advice on how best to address that little niggle (or whether I can ignore it) appreciated. Cheers, Rob |
From: JonY <10...@gm...> - 2009-08-25 05:57:13
|
On 8/25/2009 13:01, Sisyphus wrote: > /bin/sh ../../libtool --mode=link x86_64-w64-mingw32-gcc -O2 -pedantic > -o t-locale.exe t-locale.o ../../tests/libtests.la ../../libgmp.la > x86_64-w64-mingw32-gcc -O2 -pedantic -o t-locale.exe t-locale.o > ../../tests/.libs/libtests.a /c/_32/comp/gmp-4.3.1/.libs/libgmp.a > ../../.libs/libgmp.a > c:/_64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/libmsvcrt.a(dslcs00660.o):(.text+0x0): > multiple definition of `localeconv' > t-locale.o:t-locale.c:(.text+0x0): first defined here > collect2: ld returned 1 exit status > make[4]: *** [t-locale.exe] Error 1 > make[4]: Leaving directory `/c/_32/comp/gmp-4.3.1/tests/misc' > make[3]: *** [check-am] Error 2 > make[3]: Leaving directory `/c/_32/comp/gmp-4.3.1/tests/misc' > make[2]: *** [check-recursive] Error 1 > make[2]: Leaving directory `/c/_32/comp/gmp-4.3.1/tests' > make[1]: *** [check-recursive] Error 1 > make[1]: Leaving directory `/c/_32/comp/gmp-4.3.1' > make: *** [check] Error 2 > #################################### > > Any advice on how best to address that little niggle (or whether I can > ignore it) appreciated. > > Cheers, > Rob > Hi, I got to this point too, the localeconv provided in msvcrt unfortunately can't be replaced easily, so this test is expected to fail. You can ignore it. |
From: Sisyphus <sis...@op...> - 2009-08-26 02:44:29
|
----- Original Message ----- From: "JonY" <10...@gm...> > Hi, > I got to this point too, the localeconv provided in msvcrt unfortunately > can't be replaced easily, so this test is expected to fail. You can > ignore it. > Good - no other problems with gmp-4.3.1. With mpfr-2.4.1, some of the *printf tests fail. From similar experiences I had building with gcc-3.4.5 (32 bit), I know this doesn't necessarily mean there's something wrong with the compiler. I'll have to take a closer look when I have more time. (For the moment, I just wanted to get this built.) Here are the test errors: Error in test #8: mpfr_printf printed td characters instead of 22 FAIL: tprintf.exe Error in mpfr_vsprintf (s, "%.*Zi, %R*e, %Lf", ...); expected: "00000010610209857723, -1.2345678875e+07, 0.032258" got: "00000010610209857723, -1.2345678875e+07, 0.000000" FAIL: tsprintf.exe Error in test #8: mpfr_vfprintf printed td characters instead of 22 FAIL: tfprintf.exe PASS: trec_sqrt.exe PASS: tpow_all.exe ===================== 3 of 148 tests failed ===================== With mpc-0.6 I get an error building the mpc_set tests (tset.o): x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I/usr/local/include -g -O2 -MT tset.o -MD -MP -MF .deps/tset.Tpo -c -o tset.o tset.c In file included from ../src/mpc-impl.h:27:0, from mpc-tests.h:25, from tset.c:37: ../src/config.h:1:0: warning: "PACKAGE_STRING" redefined ../config.h:71:0: note: this is the location of the previous definition mv -f .deps/tset.Tpo .deps/tset.Po /bin/sh ../libtool --tag=CC --mode=link 86_64-w64-mingw32-gcc -g -O2 -L/usr/local/lib -o tset.exe tset.o libmpc-tests.la ../src/libmpc.la -lmpfr -lgmp x86_64-w64-mingw32-gcc -g -O2 -o tset.exe tset.o -L/usr/local/lib ./.libs/libmpc-tests.a ../src/.libs/libmpc.a /usr/local/lib/libmpfr.a /usr/local/lib/libgmp.a tset.o: In function `check_set': c:\_32\comp\mpc-0.6\tests/tset.c:235: undefined reference to `mpc_set_uj' c:\_32\comp\mpc-0.6\tests/tset.c:240: undefined reference to `mpc_set_sj' c:\_32\comp\mpc-0.6\tests/tset.c:245: undefined reference to `mpc_set_uj_uj' c:\_32\comp\mpc-0.6\tests/tset.c:250: undefined reference to `mpc_set_sj_sj' c:\_32\comp\mpc-0.6\tests/tset.c:259: undefined reference to `mpc_set_sj' c:\_32\comp\mpc-0.6\tests/tset.c:264: undefined reference to `mpc_set_sj_sj' collect2: ld returned 1 exit status make[2]: *** [tset.exe] Error 1 This a little more serious - those references are, indeed, not defined in libmpc.a. This smells to me like a bug in mpc itself. (Again, I'll have to take a closer look when time permits.) Thanks again for all the help. Cheers, Rob |
From: JonY <10...@gm...> - 2009-08-26 05:58:29
|
On 8/26/2009 09:31, Sisyphus wrote: > > With mpc-0.6 I get an error building the mpc_set tests (tset.o): > > x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I../src > -I/usr/local/include -g -O2 -MT tset.o -MD -MP -MF .deps/tset.Tpo -c -o > tset.o tset.c > In file included from ../src/mpc-impl.h:27:0, > from mpc-tests.h:25, > from tset.c:37: > ../src/config.h:1:0: warning: "PACKAGE_STRING" redefined > ../config.h:71:0: note: this is the location of the previous definition > mv -f .deps/tset.Tpo .deps/tset.Po > /bin/sh ../libtool --tag=CC --mode=link 86_64-w64-mingw32-gcc -g -O2 > -L/usr/local/lib -o tset.exe tset.o libmpc-tests.la ../src/libmpc.la > -lmpfr -lgmp > x86_64-w64-mingw32-gcc -g -O2 -o tset.exe tset.o -L/usr/local/lib > ./.libs/libmpc-tests.a ../src/.libs/libmpc.a /usr/local/lib/libmpfr.a > /usr/local/lib/libgmp.a > tset.o: In function `check_set': > c:\_32\comp\mpc-0.6\tests/tset.c:235: undefined reference to `mpc_set_uj' > c:\_32\comp\mpc-0.6\tests/tset.c:240: undefined reference to `mpc_set_sj' > c:\_32\comp\mpc-0.6\tests/tset.c:245: undefined reference to > `mpc_set_uj_uj' > c:\_32\comp\mpc-0.6\tests/tset.c:250: undefined reference to > `mpc_set_sj_sj' > c:\_32\comp\mpc-0.6\tests/tset.c:259: undefined reference to `mpc_set_sj' > c:\_32\comp\mpc-0.6\tests/tset.c:264: undefined reference to > `mpc_set_sj_sj' > collect2: ld returned 1 exit status > make[2]: *** [tset.exe] Error 1 > > This a little more serious - those references are, indeed, not defined > in libmpc.a. This smells to me like a bug in mpc itself. (Again, I'll > have to take a closer look when time permits.) > Hi, this looks like a real problem, I haven't encountered it before. I'll investigate further once I get the time; or until xeno shows up on irc, he's been doing trying to make a win64 toolchain too. I'm sure he has something to say. |