From epeterson at mocana.com Thu Jul 3 19:55:55 2008 From: epeterson at mocana.com (Erik Peterson) Date: Thu, 3 Jul 2008 10:55:55 -0700 Subject: GMP on mips64 ... Message-ID: Hello, I have built gmp for mips targeting mips on a IA linux machine. The build appears fine, however the "make check" is showing test case errors bellow. These are the commands I used to do the cross-compiling: ../configure --target=mips64-octeon-linux-gnu --host=mips64-octeon- linux-gnu --prefix=/opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target make make install I have attached the output for makecheckout.txt [root at bisonsv target]# make check >> makecheckout.txt ./t-bswap: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target/ tests/.libs/lt-t-bswap: cannot execute binary file ./t-bswap: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target/ tests/.libs/lt-t-bswap: Success ./t-constants: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target/ tests/.libs/lt-t-constants: cannot execute binary file ./t-constants: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target/ tests/.libs/lt-t-constants: Success ./t-count_zeros: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/ target/tests/.libs/lt-t-count_zeros: cannot execute binary file ./t-count_zeros: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/ target/tests/.libs/lt-t-count_zeros: Success ./t-gmpmax: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target/ tests/.libs/lt-t-gmpmax: cannot execute binary file ./t-gmpmax: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target/ tests/.libs/lt-t-gmpmax: Success ./t-hightomask: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/ target/tests/.libs/lt-t-hightomask: cannot execute binary file ./t-hightomask: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/ target/tests/.libs/lt-t-hightomask: Success ./t-modlinv: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target/ tests/.libs/lt-t-modlinv: cannot execute binary file ./t-modlinv: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target/ tests/.libs/lt-t-modlinv: Success ./t-popc: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target/ tests/.libs/lt-t-popc: cannot execute binary file ./t-popc: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target/ tests/.libs/lt-t-popc: Success ./t-parity: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target/ tests/.libs/lt-t-parity: cannot execute binary file ./t-parity: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target/ tests/.libs/lt-t-parity: Success ./t-sub: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target/ tests/.libs/lt-t-sub: cannot execute binary file ./t-sub: line 119: /opt/OCTEON-SDK/mocana/tools/gmp-4.2.2/target/ tests/.libs/lt-t-sub: Success make[4]: *** [check-TESTS] Error 1 make[3]: *** [check-am] Error 2 make[2]: *** [check-recursive] Error 1 make[1]: *** [check-recursive] Error 1 make: *** [check] Error 2 make check-recursive make[1]: Entering directory `/space/opt/OCTEON-SDK/mocana/tools/ gmp-4.2.2/target ' Making check in tests make[2]: Entering directory `/space/opt/OCTEON-SDK/mocana/tools/ gmp-4.2.2/target /tests' Making check in . make[3]: Entering directory `/space/opt/OCTEON-SDK/mocana/tools/ gmp-4.2.2/target /tests' make libtests.la t-bswap t-constants t-count_zeros t-gmpmax t- hightomask t-modl inv t-popc t-parity t-sub make[4]: Entering directory `/space/opt/OCTEON-SDK/mocana/tools/ gmp-4.2.2/target /tests' make[4]: `libtests.la' is up to date. make[4]: `t-bswap' is up to date. make[4]: `t-constants' is up to date. make[4]: `t-count_zeros' is up to date. make[4]: `t-gmpmax' is up to date. make[4]: `t-hightomask' is up to date. make[4]: `t-modlinv' is up to date. make[4]: `t-popc' is up to date. make[4]: `t-parity' is up to date. make[4]: `t-sub' is up to date. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: makecheckout.txt Url: http://swox.com/list-archives/gmp-bugs/attachments/20080703/2bb2adbb/attachment.txt -------------- next part -------------- From vincent at vinc17.org Fri Jul 11 14:03:06 2008 From: vincent at vinc17.org (Vincent Lefevre) Date: Fri, 11 Jul 2008 14:03:06 +0200 Subject: GMP 4.2.2 doesn't recognize Xeon as 64 bits Message-ID: <20080711120306.GA23449@vin.lip.ens-lyon.fr> Perhaps a known problem but I haven't found it in the gmp-bugs archives. Here's processor information: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5440 @ 2.83GHz stepping : 6 cpu MHz : 2833.000 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips : 5656.28 clflush size : 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: psmn-newcomp1:~/software/gmp-4.2.2> ./configfsf.guess x86_64-unknown-linux-gnu and here's the beginning of the config.log: This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by GNU MP configure 4.2.2, which was generated by GNU Autoconf 2.59. Invocation command line was $ ./configure --prefix=/home/vlefevre --exec-prefix=/home/vlefevre/x86_64-linux ## --------- ## ## Platform. ## ## --------- ## hostname = psmn-newcomp1 uname -m = x86_64 uname -r = 2.6.18-92.el5 uname -s = Linux uname -v = #1 SMP Tue Apr 29 13:16:15 EDT 2008 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/sge/bin/lx24-amd64 PATH: /home/vlefevre/bin PATH: /home/vlefevre/x86_64-linux/bin PATH: /usr/local/bin PATH: /bin PATH: /usr/bin PATH: /etc PATH: /sbin PATH: /usr/sbin PATH: . ## ----------- ## ## Core tests. ## ## ----------- ## configure:1654: checking build system type configure:1672: result: pentium3-unknown-linux-gnu configure:1680: checking host system type configure:1694: result: pentium3-unknown-linux-gnu configure:1717: checking for a BSD-compatible install configure:1772: result: /usr/bin/install -c configure:1783: checking whether build environment is sane configure:1826: result: yes configure:1883: checking for gawk configure:1899: found /bin/gawk configure:1909: result: gawk configure:1919: checking whether make sets $(MAKE) configure:1939: result: yes configure:2105: checking whether to enable maintainer-specific portions of Makefiles configure:2114: result: no User: ABI= CC= CFLAGS=(unset) CPPFLAGS=(unset) MPN_PATH= GMP: abilist=32 cclist=gcc icc cc configure:3794: gcc 2>&1 | grep xlc >/dev/null configure:3797: $? = 1 configure:3851: checking compiler gcc -m32 -O2 -fomit-frame-pointer Test compile: configure:3865: gcc -m32 -O2 -fomit-frame-pointer conftest.c >&5 configure:3868: $? = 0 configure:3873: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:3876: $? = 0 Test compile: function pointer return configure:3919: gcc -m32 -O2 -fomit-frame-pointer conftest.c >&5 configure:3922: $? = 0 configure:3927: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:3930: $? = 0 Test compile: cmov instruction configure:3975: gcc -m32 -O2 -fomit-frame-pointer conftest.c >&5 configure:3978: $? = 0 configure:3983: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:3986: $? = 0 Test compile: double -> ulong conversion configure:4032: gcc -m32 -O2 -fomit-frame-pointer conftest.c >&5 configure:4035: $? = 0 configure:4040: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:4043: $? = 0 Test compile: double negation configure:4087: gcc -m32 -O2 -fomit-frame-pointer conftest.c >&5 configure:4090: $? = 0 configure:4095: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:4098: $? = 0 Test compile: double -> float conversion configure:4143: gcc -m32 -O2 -fomit-frame-pointer conftest.c >&5 configure:4146: $? = 0 configure:4151: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:4154: $? = 0 Test compile: gnupro alpha ev6 char spilling configure:4227: gcc -m32 -O2 -fomit-frame-pointer conftest.c >&5 conftest.c: In function 'param_init': conftest.c:18: warning: incompatible implicit declaration of built-in function 'memcpy' configure:4230: $? = 0 configure:4235: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:4238: $? = 0 Test compile: __builtin_alloca availability configure:4278: gcc -m32 -O2 -fomit-frame-pointer conftest.c >&5 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib/crt1.o: In function `_start': (.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status configure:4281: $? = 1 failed program was: int k; int foo () { __builtin_alloca (k); } Test compile: abs int -> double conversion configure:4402: gcc -m32 -O2 -fomit-frame-pointer conftest.c >&5 configure:4405: $? = 0 configure:4410: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:4413: $? = 0 Test compile: long long reliability test 1 configure:4466: gcc -m32 -O2 -fomit-frame-pointer conftest.c >&5 configure:4469: $? = 0 configure:4474: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:4477: $? = 0 Test compile: long long reliability test 2 configure:4526: gcc -m32 -O2 -fomit-frame-pointer conftest.c >&5 configure:4529: $? = 0 configure:4534: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:4537: $? = 0 Test compile: mpn_lshift_com optimization configure:4617: gcc -m32 -O2 -fomit-frame-pointer conftest.c >&5 configure:4620: $? = 0 configure:4625: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:4628: $? = 0 Test compile: mpn_lshift_com optimization 2 configure:4717: gcc -m32 -O2 -fomit-frame-pointer conftest.c >&5 configure:4720: $? = 0 configure:4725: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:4728: $? = 0 Testing gcc GOT with eax emitted configure:4776: gcc -m32 -O2 -fomit-frame-pointer -fPIC -S conftest.c >&5 2>&1 configure:4779: $? = 0 Result: no configure:4874: result: yes configure: testlist sizeof-long-4 configure:5049: checking compiler gcc -m32 -O2 -fomit-frame-pointer has sizeof(long)==4 configure:5062: gcc -m32 -O2 -fomit-frame-pointer -c conftest.c >&5 configure:5065: $? = 0 configure:5070: result: yes configure:5343: checking compiler gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 Test compile: configure:5357: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 conftest.c >&5 configure:5360: $? = 0 configure:5365: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5368: $? = 0 Test compile: function pointer return configure:5411: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 conftest.c >&5 configure:5414: $? = 0 configure:5419: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5422: $? = 0 Test compile: cmov instruction configure:5467: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 conftest.c >&5 configure:5470: $? = 0 configure:5475: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5478: $? = 0 Test compile: double -> ulong conversion configure:5524: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 conftest.c >&5 configure:5527: $? = 0 configure:5532: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5535: $? = 0 Test compile: double negation configure:5579: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 conftest.c >&5 configure:5582: $? = 0 configure:5587: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5590: $? = 0 Test compile: double -> float conversion configure:5635: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 conftest.c >&5 configure:5638: $? = 0 configure:5643: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5646: $? = 0 Test compile: gnupro alpha ev6 char spilling configure:5719: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 conftest.c >&5 conftest.c: In function 'param_init': conftest.c:18: warning: incompatible implicit declaration of built-in function 'memcpy' configure:5722: $? = 0 configure:5727: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5730: $? = 0 Test compile: __builtin_alloca availability configure:5770: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 conftest.c >&5 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib/crt1.o: In function `_start': (.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status configure:5773: $? = 1 failed program was: int k; int foo () { __builtin_alloca (k); } Test compile: abs int -> double conversion configure:5894: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 conftest.c >&5 configure:5897: $? = 0 configure:5902: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5905: $? = 0 Test compile: long long reliability test 1 configure:5958: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 conftest.c >&5 configure:5961: $? = 0 configure:5966: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5969: $? = 0 Test compile: long long reliability test 2 configure:6018: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 conftest.c >&5 configure:6021: $? = 0 configure:6026: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:6029: $? = 0 Test compile: mpn_lshift_com optimization configure:6109: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 conftest.c >&5 configure:6112: $? = 0 configure:6117: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:6120: $? = 0 Test compile: mpn_lshift_com optimization 2 configure:6209: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 conftest.c >&5 configure:6212: $? = 0 configure:6217: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:6220: $? = 0 Testing gcc GOT with eax emitted configure:6268: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -fPIC -S conftest.c >&5 2>&1 configure:6271: $? = 0 Result: no configure:6366: result: yes configure:5343: checking compiler gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 Test compile: configure:5357: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:5360: $? = 0 configure:5365: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5368: $? = 0 Test compile: function pointer return configure:5411: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:5414: $? = 0 configure:5419: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5422: $? = 0 Test compile: cmov instruction configure:5467: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:5470: $? = 0 configure:5475: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5478: $? = 0 Test compile: double -> ulong conversion configure:5524: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:5527: $? = 0 configure:5532: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5535: $? = 0 Test compile: double negation configure:5579: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:5582: $? = 0 configure:5587: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5590: $? = 0 Test compile: double -> float conversion configure:5635: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:5638: $? = 0 configure:5643: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5646: $? = 0 Test compile: gnupro alpha ev6 char spilling configure:5719: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 conftest.c: In function 'param_init': conftest.c:18: warning: incompatible implicit declaration of built-in function 'memcpy' configure:5722: $? = 0 configure:5727: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5730: $? = 0 Test compile: __builtin_alloca availability configure:5770: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib/crt1.o: In function `_start': (.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status configure:5773: $? = 1 failed program was: int k; int foo () { __builtin_alloca (k); } Test compile: abs int -> double conversion configure:5894: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:5897: $? = 0 configure:5902: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5905: $? = 0 Test compile: long long reliability test 1 configure:5958: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:5961: $? = 0 configure:5966: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:5969: $? = 0 Test compile: long long reliability test 2 configure:6018: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:6021: $? = 0 configure:6026: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:6029: $? = 0 Test compile: mpn_lshift_com optimization configure:6109: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:6112: $? = 0 configure:6117: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:6120: $? = 0 Test compile: mpn_lshift_com optimization 2 configure:6209: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:6212: $? = 0 configure:6217: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest configure:6220: $? = 0 Testing gcc GOT with eax emitted configure:6268: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 -fPIC -S conftest.c >&5 2>&1 configure:6271: $? = 0 Result: no configure:6366: result: yes configure:6515: checking for gcc configure:6541: result: gcc configure:6785: checking for C compiler version configure:6788: gcc --version &5 gcc (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:6791: $? = 0 configure:6793: gcc -v &5 Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20071124 (Red Hat 4.1.2-42) configure:6796: $? = 0 configure:6798: gcc -V &5 gcc: '-V' option must have argument configure:6801: $? = 1 configure:6824: checking for C compiler default output file name configure:6827: gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:6830: $? = 0 configure:6876: result: a.out configure:6881: checking whether the C compiler works configure:6887: ./a.out configure:6890: $? = 0 configure:6907: result: yes configure:6914: checking whether we are cross compiling configure:6916: result: no configure:6919: checking for suffix of executables configure:6921: gcc -o conftest -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:6924: $? = 0 configure:6949: result: configure:6955: checking for suffix of object files configure:6976: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:6979: $? = 0 configure:7001: result: o configure:7005: checking whether we are using the GNU C compiler configure:7029: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:7035: $? = 0 configure:7039: test -z || test ! -s conftest.err configure:7042: $? = 0 configure:7045: test -s conftest.o configure:7048: $? = 0 configure:7061: result: yes configure:7067: checking whether gcc accepts -g configure:7088: gcc -c -g conftest.c >&5 configure:7094: $? = 0 configure:7098: test -z || test ! -s conftest.err configure:7101: $? = 0 configure:7104: test -s conftest.o configure:7107: $? = 0 configure:7118: result: yes configure:7135: checking for gcc option to accept ANSI C configure:7205: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:7211: $? = 0 configure:7215: test -z || test ! -s conftest.err configure:7218: $? = 0 configure:7221: test -s conftest.o configure:7224: $? = 0 configure:7242: result: none needed configure:7260: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 conftest.c:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'me' configure:7266: $? = 1 configure: failed program was: | #ifndef __cplusplus | choke me | #endif configure:7405: checking how to run the C preprocessor configure:7440: gcc -E conftest.c configure:7446: $? = 0 configure:7478: gcc -E conftest.c conftest.c:15:28: error: ac_nonexistent.h: No such file or directory configure:7484: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "GNU MP" | #define PACKAGE_TARNAME "gmp" | #define PACKAGE_VERSION "4.2.2" | #define PACKAGE_STRING "GNU MP 4.2.2" | #define PACKAGE_BUGREPORT "gmp-bugs at swox.com" | #define PACKAGE "gmp" | #define VERSION "4.2.2" | #define WANT_FFT 1 | #define HAVE_HOST_CPU_pentium3 1 | #define HAVE_SPEED_CYCLECOUNTER 2 | #define HAVE_CALLING_CONVENTIONS 1 | /* end confdefs.h. */ | #include configure:7523: result: gcc -E configure:7547: gcc -E conftest.c configure:7553: $? = 0 configure:7585: gcc -E conftest.c conftest.c:15:28: error: ac_nonexistent.h: No such file or directory configure:7591: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "GNU MP" | #define PACKAGE_TARNAME "gmp" | #define PACKAGE_VERSION "4.2.2" | #define PACKAGE_STRING "GNU MP 4.2.2" | #define PACKAGE_BUGREPORT "gmp-bugs at swox.com" | #define PACKAGE "gmp" | #define VERSION "4.2.2" | #define WANT_FFT 1 | #define HAVE_HOST_CPU_pentium3 1 | #define HAVE_SPEED_CYCLECOUNTER 2 | #define HAVE_CALLING_CONVENTIONS 1 | /* end confdefs.h. */ | #include configure:7666: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:7672: $? = 0 configure:7676: test -z || test ! -s conftest.err configure:7679: $? = 0 configure:7682: test -s conftest.o configure:7685: $? = 0 configure:7773: checking build system compiler gcc configure:7786: gcc conftest.c conftest.c: In function 'main': conftest.c:4: warning: incompatible implicit declaration of built-in function 'exit' configure:7789: $? = 0 configure:7796: result: yes configure:7817: checking for build system preprocessor configure:7828: gcc -E conftest.c # 1 "conftest.c" # 1 "" # 1 "" # 1 "conftest.c" configure:7831: $? = 0 configure:7848: result: gcc -E configure:7855: checking for build system executable suffix configure:7869: gcc conftest.c -o conftest.exe conftest.c: In function 'main': conftest.c:4: warning: incompatible implicit declaration of built-in function 'exit' configure:7872: $? = 0 ./configure: line 7874: ./conftest: No such file or directory configure:7869: gcc conftest.c -o conftest,ff8 conftest.c: In function 'main': conftest.c:4: warning: incompatible implicit declaration of built-in function 'exit' configure:7872: $? = 0 ./configure: line 7874: ./conftest: No such file or directory configure:7869: gcc conftest.c -o conftest conftest.c: In function 'main': conftest.c:4: warning: incompatible implicit declaration of built-in function 'exit' configure:7872: $? = 0 configure:7888: result: configure:7894: checking whether build system compiler is ANSI configure:7907: gcc conftest.c conftest.c: In function 'main': conftest.c:4: warning: incompatible implicit declaration of built-in function 'exit' configure:7910: $? = 0 configure:7919: result: yes configure:7929: checking for build system compiler math library configure:7948: gcc conftest.c -lm conftest.c: In function 'main': conftest.c:4: warning: incompatible implicit declaration of built-in function 'exit' conftest.c: In function 'foo': conftest.c:10: warning: incompatible implicit declaration of built-in function 'log' configure:7951: $? = 0 configure:7960: result: -lm configure:8770: checking for egrep configure:8780: result: grep -E configure:8851: checking if the assembler knows about MMX instructions configure:8861: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.s >conftest.out 2>&1 configure:8864: $? = 0 configure:8888: result: yes Decided: ABI=32 CC=gcc CFLAGS=-m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 CPPFLAGS= GMP_LDFLAGS= CXX= CXXFLAGS= path= x86/p6/p3mmx x86/p6/mmx x86/p6 x86 generic configure:9054: checking for function prototypes configure:9057: result: yes configure:9074: checking for ANSI C header files configure:9099: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:9105: $? = 0 configure:9109: test -z || test ! -s conftest.err configure:9112: $? = 0 configure:9115: test -s conftest.o configure:9118: $? = 0 configure:9207: gcc -o conftest -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 conftest.c: In function 'main': conftest.c:34: warning: incompatible implicit declaration of built-in function 'exit' configure:9210: $? = 0 configure:9212: ./conftest configure:9215: $? = 0 configure:9230: result: yes configure:9254: checking for sys/types.h configure:9270: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:9276: $? = 0 configure:9280: test -z || test ! -s conftest.err configure:9283: $? = 0 configure:9286: test -s conftest.o configure:9289: $? = 0 configure:9300: result: yes configure:9254: checking for sys/stat.h configure:9270: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:9276: $? = 0 configure:9280: test -z || test ! -s conftest.err configure:9283: $? = 0 configure:9286: test -s conftest.o configure:9289: $? = 0 configure:9300: result: yes configure:9254: checking for stdlib.h configure:9270: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:9276: $? = 0 configure:9280: test -z || test ! -s conftest.err configure:9283: $? = 0 configure:9286: test -s conftest.o configure:9289: $? = 0 configure:9300: result: yes configure:9254: checking for string.h configure:9270: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:9276: $? = 0 configure:9280: test -z || test ! -s conftest.err configure:9283: $? = 0 configure:9286: test -s conftest.o configure:9289: $? = 0 configure:9300: result: yes configure:9254: checking for memory.h configure:9270: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:9276: $? = 0 configure:9280: test -z || test ! -s conftest.err configure:9283: $? = 0 configure:9286: test -s conftest.o configure:9289: $? = 0 configure:9300: result: yes configure:9254: checking for strings.h configure:9270: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:9276: $? = 0 configure:9280: test -z || test ! -s conftest.err configure:9283: $? = 0 configure:9286: test -s conftest.o configure:9289: $? = 0 configure:9300: result: yes configure:9254: checking for inttypes.h configure:9270: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:9276: $? = 0 configure:9280: test -z || test ! -s conftest.err configure:9283: $? = 0 configure:9286: test -s conftest.o configure:9289: $? = 0 configure:9300: result: yes configure:9254: checking for stdint.h configure:9270: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:9276: $? = 0 configure:9280: test -z || test ! -s conftest.err configure:9283: $? = 0 configure:9286: test -s conftest.o configure:9289: $? = 0 configure:9300: result: yes configure:9254: checking for unistd.h configure:9270: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:9276: $? = 0 configure:9280: test -z || test ! -s conftest.err configure:9283: $? = 0 configure:9286: test -s conftest.o configure:9289: $? = 0 configure:9300: result: yes configure:9325: checking for string.h configure:9330: result: yes configure:9515: checking for ar configure:9531: found /usr/bin/ar configure:9542: result: ar configure:9573: checking for BSD-compatible nm configure:9622: result: /usr/bin/nm -B configure:9894: checking for a sed that does not truncate output configure:9950: result: /bin/sed configure:9964: checking for ld used by gcc configure:10031: result: /usr/bin/ld configure:10040: checking if the linker (/usr/bin/ld) is GNU ld configure:10055: result: yes configure:10060: checking for /usr/bin/ld option to reload object files configure:10067: result: -r configure:10085: checking whether ln -s works configure:10089: result: yes configure:10096: checking how to recognize dependent libraries configure:10282: result: pass_all configure:10776: checking dlfcn.h usability configure:10788: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:10794: $? = 0 configure:10798: test -z || test ! -s conftest.err configure:10801: $? = 0 configure:10804: test -s conftest.o configure:10807: $? = 0 configure:10817: result: yes configure:10821: checking dlfcn.h presence configure:10831: gcc -E conftest.c configure:10837: $? = 0 configure:10857: result: yes configure:10892: checking for dlfcn.h configure:10899: result: yes configure:11155: checking the maximum length of command line arguments configure:11267: result: 98304 configure:11279: checking command to parse /usr/bin/nm -B output from gcc object configure:11384: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c >&5 configure:11387: $? = 0 configure:11391: /usr/bin/nm -B conftest.o \| sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' \> conftest.nm configure:11394: $? = 0 configure:11446: gcc -o conftest -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 conftest.c conftstm.o >&5 configure:11449: $? = 0 configure:11487: result: ok configure:11491: checking for objdir configure:11506: result: .libs configure:11596: checking for ar configure:11623: result: ar configure:11676: checking for ranlib configure:11692: found /usr/bin/ranlib configure:11703: result: ranlib configure:11756: checking for strip configure:11772: found /usr/bin/strip configure:11783: result: strip configure:12055: checking if gcc supports -fno-rtti -fno-exceptions configure:12073: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 -fno-rtti -fno-exceptions conftest.c >&5 cc1: warning: command line option "-fno-rtti" is valid for C++/ObjC++ but not for C configure:12077: $? = 0 configure:12090: result: no configure:12105: checking for gcc option to produce PIC configure:12337: result: -fPIC configure:12345: checking if gcc PIC flag -fPIC works configure:12363: gcc -c -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 -fPIC -DPIC conftest.c >&5 configure:12367: $? = 0 configure:12380: result: yes configure:12408: checking if gcc static flag -static works ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=pentium3-unknown-linux-gnu ac_cv_build_alias=pentium3-unknown-linux-gnu ac_cv_c_compiler_gnu=yes ac_cv_env_ABI_set= ac_cv_env_ABI_value= ac_cv_env_CC_FOR_BUILD_set= ac_cv_env_CC_FOR_BUILD_value= ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_FOR_BUILD_set= ac_cv_env_CPP_FOR_BUILD_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_CXXCPP_set= ac_cv_env_CXXCPP_value= ac_cv_env_CXXFLAGS_set= ac_cv_env_CXXFLAGS_value= ac_cv_env_CXX_set= ac_cv_env_CXX_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_M4_set= ac_cv_env_M4_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_exeext= ac_cv_header_dlfcn_h=yes ac_cv_header_inttypes_h=yes ac_cv_header_memory_h=yes ac_cv_header_stdc=yes ac_cv_header_stdint_h=yes ac_cv_header_stdlib_h=yes ac_cv_header_string_h=yes ac_cv_header_strings_h=yes ac_cv_header_sys_stat_h=yes ac_cv_header_sys_types_h=yes ac_cv_header_unistd_h=yes ac_cv_host=pentium3-unknown-linux-gnu ac_cv_host_alias=pentium3-unknown-linux-gnu ac_cv_objext=o ac_cv_path_install='/usr/bin/install -c' ac_cv_prog_AWK=gawk ac_cv_prog_CPP='gcc -E' ac_cv_prog_ac_ct_AR=ar ac_cv_prog_ac_ct_CC=gcc ac_cv_prog_ac_ct_RANLIB=ranlib ac_cv_prog_ac_ct_STRIP=strip ac_cv_prog_cc_g=yes ac_cv_prog_cc_stdc= ac_cv_prog_egrep='grep -E' ac_cv_prog_make_make_set=yes gmp_cv_asm_x86_mmx=yes gmp_cv_c_for_build_ansi=yes gmp_cv_check_libm_for_build=-lm gmp_cv_prog_cpp_for_build='gcc -E' gmp_cv_prog_exeext_for_build= lt_cv_deplibs_check_method=pass_all lt_cv_file_magic_cmd='$MAGIC_CMD' lt_cv_file_magic_test_file= lt_cv_ld_reload_flag=-r lt_cv_objdir=.libs lt_cv_path_LD=/usr/bin/ld lt_cv_path_NM='/usr/bin/nm -B' lt_cv_path_SED=/bin/sed lt_cv_prog_compiler_rtti_exceptions=no lt_cv_prog_gnu_ld=yes lt_cv_sys_global_symbol_pipe='sed -n -e '\''s/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p'\''' lt_cv_sys_global_symbol_to_c_name_address='sed -n -e '\''s/^: \([^ ]*\) $/ {\"\1\", (lt_ptr) 0},/p'\'' -e '\''s/^[BCDEGRST] \([^ ]*\) \([^ ]*\)$/ {"\2", (lt_ptr) \&\2},/p'\''' lt_cv_sys_global_symbol_to_cdecl='sed -n -e '\''s/^. .* \(.*\)$/extern int \1;/p'\''' lt_cv_sys_max_cmd_len=98304 ## ----------------- ## ## Output variables. ## ## ----------------- ## ABI='32' ACLOCAL='${SHELL} /home/vlefevre/software/gmp-4.2.2/missing --run aclocal-1.8' AMTAR='${SHELL} /home/vlefevre/software/gmp-4.2.2/missing --run tar' ANSI2KNR='' AR='ar' AS='as' AUTOCONF='${SHELL} /home/vlefevre/software/gmp-4.2.2/missing --run autoconf' AUTOHEADER='${SHELL} /home/vlefevre/software/gmp-4.2.2/missing --run autoheader' AUTOMAKE='${SHELL} /home/vlefevre/software/gmp-4.2.2/missing --run automake-1.8' AWK='gawk' BITS_PER_MP_LIMB='' CALLING_CONVENTIONS_OBJS='x86call.lo x86check$U.lo' CC='gcc' CCAS='gcc -c' CC_FOR_BUILD='gcc' CFLAGS='-m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3' CPP='gcc -E' CPPFLAGS='' CPP_FOR_BUILD='gcc -E' CXX='' CXXCPP='' CXXFLAGS='' CYGPATH_W='echo' DEFN_LONG_LONG_LIMB='/* #undef _LONG_LONG_LIMB */' DEFS='' DLLTOOL='dlltool' ECHO='echo' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='grep -E' ENABLE_STATIC_FALSE='' ENABLE_STATIC_TRUE='' EXEEXT='' EXEEXT_FOR_BUILD='' GMP_LDFLAGS='' GMP_NAIL_BITS='0' HAVE_CLOCK_01='' HAVE_CPUTIME_01='' HAVE_GETRUSAGE_01='' HAVE_GETTIMEOFDAY_01='' HAVE_HOST_CPU_FAMILY_power='0' HAVE_HOST_CPU_FAMILY_powerpc='0' HAVE_SIGACTION_01='' HAVE_SIGALTSTACK_01='' HAVE_SIGSTACK_01='' HAVE_STACK_T_01='' HAVE_SYS_RESOURCE_H_01='' INSTALL_DATA='${INSTALL} -m 644' INSTALL_PROGRAM='${INSTALL}' INSTALL_SCRIPT='${INSTALL}' INSTALL_STRIP_PROGRAM='${SHELL} $(install_sh) -c -s' LDFLAGS='' LEX='' LEXLIB='' LEX_OUTPUT_ROOT='' LIBCURSES='' LIBGMPXX_LDFLAGS='' LIBGMP_DLL='0' LIBGMP_LDFLAGS='' LIBM='' LIBM_FOR_BUILD='-lm' LIBOBJS='' LIBREADLINE='' LIBS='' LIBTOOL='' LN_S='ln -s' LTLIBOBJS='' M4='' MAINT='#' MAINTAINER_MODE_FALSE='' MAINTAINER_MODE_TRUE='#' MAKEINFO='${SHELL} /home/vlefevre/software/gmp-4.2.2/missing --run makeinfo' OBJDUMP='objdump' OBJEXT='o' PACKAGE='gmp' PACKAGE_BUGREPORT='gmp-bugs at swox.com' PACKAGE_NAME='GNU MP' PACKAGE_STRING='GNU MP 4.2.2' PACKAGE_TARNAME='gmp' PACKAGE_VERSION='4.2.2' PATH_SEPARATOR=':' RANLIB='ranlib' SED='/bin/sed' SET_MAKE='' SHELL='/bin/sh' SPEED_CYCLECOUNTER_OBJ='pentium.lo' STRIP='strip' TAL_OBJECT='' TUNE_SQR_OBJ='' U='' U_FOR_BUILD='' VERSION='4.2.2' WANT_CXX_FALSE='' WANT_CXX_TRUE='#' WANT_MPBSD_FALSE='' WANT_MPBSD_TRUE='#' WITH_READLINE_01='' YACC='' ac_ct_AR='ar' ac_ct_AS='' ac_ct_CC='gcc' ac_ct_CXX='' ac_ct_DLLTOOL='' ac_ct_OBJDUMP='' ac_ct_RANLIB='ranlib' ac_ct_STRIP='strip' am__leading_dot='.' bindir='${exec_prefix}/bin' build='pentium3-unknown-linux-gnu' build_alias='' build_cpu='pentium3' build_os='linux-gnu' build_vendor='unknown' datadir='${prefix}/share' exec_prefix='/home/vlefevre/x86_64-linux' gmp_srclinks='' host='pentium3-unknown-linux-gnu' host_alias='' host_cpu='pentium3' host_os='linux-gnu' host_vendor='unknown' includedir='${prefix}/include' infodir='${prefix}/info' install_sh='/home/vlefevre/software/gmp-4.2.2/install-sh' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localstatedir='${prefix}/var' mandir='${prefix}/man' mkdir_p='mkdir -p -- .' mpn_objects='' mpn_objs_in_libgmp='' mpn_objs_in_libmp='' oldincludedir='/usr/include' prefix='/home/vlefevre' program_transform_name='s,x,x,' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target_alias='' ## ----------- ## ## confdefs.h. ## ## ----------- ## #define HAVE_CALLING_CONVENTIONS 1 #define HAVE_DLFCN_H 1 #define HAVE_HOST_CPU_pentium3 1 #define HAVE_INTTYPES_H 1 #define HAVE_MEMORY_H 1 #define HAVE_SPEED_CYCLECOUNTER 2 #define HAVE_STDINT_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRINGS_H 1 #define HAVE_STRING_H 1 #define HAVE_STRING_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_UNISTD_H 1 #define PACKAGE "gmp" #define PACKAGE_BUGREPORT "gmp-bugs at swox.com" #define PACKAGE_NAME "GNU MP" #define PACKAGE_STRING "GNU MP 4.2.2" #define PACKAGE_TARNAME "gmp" #define PACKAGE_VERSION "4.2.2" #define PROTOTYPES 1 #define STDC_HEADERS 1 #define VERSION "4.2.2" #define WANT_FFT 1 #define __PROTOTYPES 1 configure: caught signal 2 configure: exit 1 -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From dmo2118 at gmail.com Sat Jul 12 08:06:28 2008 From: dmo2118 at gmail.com (Dave Odell) Date: Sat, 12 Jul 2008 02:06:28 -0400 Subject: MinGW/MSYS, GMP make check fails Message-ID: So under MinGW/MSYS, I did this: (Caveat: I also did a number of other configure/make runs using different switches in the same build tree, originally the goal was to get a build of "configure --disable-static --enable-shared --disable-fft --build=i586-pc-mingw32 --enable-cxx" working.) Dave at SHUTTLE /c/src/gmp-4.2.2 $ make clean (make clean runs OK.) $ configure --disable-static --enable-shared (configure runs OK. It correctly detects a system type of athlon64-pc-mingw32.) $ make -j 8 (make runs OK.) $ make install (make install runs OK.) $ make check And got this... make[4]: Leaving directory `/c/src/gmp-4.2.2/tests' make check-TESTS make[4]: Entering directory `/c/src/gmp-4.2.2/tests' FAIL: t-bswap.exe FAIL: t-constants.exe FAIL: t-count_zeros.exe FAIL: t-gmpmax.exe FAIL: t-hightomask.exe FAIL: t-modlinv.exe FAIL: t-popc.exe FAIL: t-parity.exe FAIL: t-sub.exe ================================== 9 of 9 tests failed Please report to gmp-bugs at swox.com ================================== make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/c/src/gmp-4.2.2/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/c/src/gmp-4.2.2/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/c/src/gmp-4.2.2/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/c/src/gmp-4.2.2' make: *** [check] Error 2 Some things I noticed: (1) Dependency Walker (www.dependencywalker.com) reports that the test programs do not reference libgmp-3.dll. Given that I'm building a DLL, this seems like the problem (2) I noticed that MinGW has had some problems in the past with GMP, so I wrote the following test program. (Note http://swox.com/list-archives/gmp-discuss/2004-August/001290.html) The following program works (compiled in MinGW, with --image-base 0x68A80000 passed to the linker so as to force a relocation of libgmp-3.dll; Microsoft DUMPBIN says that 0x68A80000 is the image base for libgmp-3.dll for some reason, not sure why): #include #include #include int main() { printf("GMP Version: %s\n", gmp_version); printf("GMP base address: %p\n", GetModuleHandle("libgmp-3.dll")); mpf_t pi, n22, n7, n22d7, result; mpf_init_set_str(pi, "3.1415926535897932384626433832795", 10); mpf_init_set_str(n22, "22", 10); mpf_init_set_str(n7, "7", 10); mpf_init(n22d7); mpf_init(result); mpf_div(n22d7, n22, n7); mpf_sub(result, n22d7, pi); mpf_out_str(stdout, 10, 32, result); putchar('\n'); mpf_clear(pi); mpf_clear(n22); mpf_clear(n7); mpf_clear(n22d7); mpf_clear(result); return 0; } ...and gives the following as output: GMP Version: 4.2.2 GMP base address: 68A80000 0.126448926734961868021e-2 ...Which is what I expect. (3) Considering that the test programs might not be executing at all, I modified t_bswap.c so that it looked like this: ... #include "windows.h" int main (void) { MessageBox(NULL, "Hello from t-bswap.exe.", NULL, MB_OK); mp_limb_t src, want, got; int i; ... No message box appeared when I ran "make check". When I ran t-bswap from the (Windows) command prompt, I didn't get a message box either. Instead I got: C:\src\gmp-4.2.2\tests>t-bswap.exe C:\src\gmp-4.2.2\tests>t-bswap t-bswap: FATAL: Couldn't find t-bswap. C:\src\gmp-4.2.2\tests> And finally, when I ran t-bswap from the Visual C++ debugger: 't-bswap.exe': Loaded 'C:\src\gmp-4.2.2\tests\t-bswap.exe', Binary was not built with debug information. 't-bswap.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No symbols loaded. 't-bswap.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No symbols loaded. 't-bswap.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', No symbols loaded. 't-bswap.exe': Loaded 'C:\WINDOWS\system32\shimeng.dll', No symbols loaded. 't-bswap.exe': Unloaded 'C:\WINDOWS\system32\shimeng.dll' The program '[5152] t-bswap.exe: Native' has exited with code 127 (0x7f). And still no message box. Finally... >> Please include the following in any report, >> * The GMP version number, and if pre-packaged or patched then say so. 4.2.2, the latest as of today, pre-packaged from ftp://ftp.gnu.org/gnu/gmp/gmp-4.2.2.tar.bz2. >> * A test program that makes it possible for us to reproduce the bug. Include instructions on how to run the program. The test program is what comes with GMP 4.2.2. >> * A description of what is wrong. If the results are incorrect, in what way. If you get a crash, say so. See above. Not a crash so much as the test programs exit before they get to main(). >> * If you get a crash, include a stack backtrace from the debugger if it's informative (`where' in gdb, or `$C' in adb). No crash, no stacktrace. >> * Please do not send core dumps, executables or straces. Alright, then. >> * The configuration options you used when building GMP, if any. configure --disable-static --enable-shared >> * The name of the compiler and its version. For gcc, get the version with `gcc -v', otherwise perhaps `what `which cc`', or similar. $ gcc -v Reading specs from c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw special) Since this might be a linker problem... $ ld -v GNU ld version 2.17.50 20060824 >> * The output from running `uname -a'. $ uname -a MINGW32_NT-5.1 SHUTTLE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown >> * The output from running `./config.guess', and from running `./configfsf.guess' (might be the same). $ config.guess athlon64-pc-mingw32 $ configsf.guess sh: configsf.guess: command not found >> * If the bug is related to `configure', then the contents of config.log. See attached. It might not be relevant, though. >> * If the bug is related to an asm file not assembling, then the contents of config.m4 and the offending line or lines from the temporary mpn/tmp-.s. It isn't. Dave Odell dmo2118 at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log.gz Type: application/x-gzip Size: 19088 bytes Desc: not available Url : http://swox.com/list-archives/gmp-bugs/attachments/20080712/380f457d/attachment-0001.bin From sisyphus1 at optusnet.com.au Mon Jul 14 05:06:37 2008 From: sisyphus1 at optusnet.com.au (Sisyphus) Date: Mon, 14 Jul 2008 13:06:37 +1000 Subject: MinGW/MSYS, GMP make check fails In-Reply-To: References: Message-ID: ----- Original Message ----- From: "Dave Odell" . . > (Caveat: I also did a number of other configure/make runs using > different switches in the same build tree, originally the goal was to > get a build of "configure --disable-static --enable-shared > --disable-fft --build=i586-pc-mingw32 --enable-cxx" working.) This issue has been raised here a couple of times previously (with no replies on both occasions, iinm). Firstly, afaik, the problem arises only with "shared" builds - not static builds. Secondly, apart from the failure of 'make check', everything seems fine. The created GMP library seems to be perfectly functional when apps are built against it. I would therefore envisage that when you build with "./configure --disable-static --enable-shared --disable-fft --build=i586-pc-mingw32 --enable-cxx" you do end up with a GMP shared library that functions correctly. It's just that you can't actually verify that by running 'make check'. (Please correct me if any of the above is wrong.) It would, of course, be good to see this problem fixed. I (tentatively) asked on the mingw mailing list whether it might be a problem with the msys shell that accounts for this failure, but that notion was scoffed at. For a workaround (untested), if you have Cygwin, you could build in the Cygwin shell, cross-compiled for native Win32 - something like "./configure --disable-static --enable-shared --disable-fft --host=i586-pc-mingw32 --build=i686-pc-cygwin --enable-cxx CC='gcc -mno-cygwin ' host_alias=i586-pc-mingw32". That might enable you to build the library the way you want it, *and* have 'make check' pass all tests. (I've done such a thing - but only for static builds of GMP. Faik, 'make check' might still fail if you cross-compile a *shared* build.) Cheers, Rob From tim.vanholder at anubex.com Mon Jul 14 09:20:14 2008 From: tim.vanholder at anubex.com (Tim Van Holder) Date: Mon, 14 Jul 2008 09:20:14 +0200 Subject: MinGW/MSYS, GMP make check fails In-Reply-To: References: Message-ID: <487AFE2E.5070602@anubex.com> On 2008-07-14 05:06, Sisyphus wrote: > ----- Original Message ----- > From: "Dave Odell" > . > . >> (Caveat: I also did a number of other configure/make runs using >> different switches in the same build tree, originally the goal was to >> get a build of "configure --disable-static --enable-shared >> --disable-fft --build=i586-pc-mingw32 --enable-cxx" working.) > > This issue has been raised here a couple of times previously (with no > replies on both occasions, iinm). > > Firstly, afaik, the problem arises only with "shared" builds - not static > builds. > Secondly, apart from the failure of 'make check', everything seems fine. The > created GMP library seems to be perfectly functional when apps are built > against it. I'm not sure what version of libtool GMP comes with, but this _may_ be a libtool bug. Maybe try (re)libtoolizing gmp with the latest release (or even prerelease) of libtool to see if the issue goes away. From tg at swox.com Wed Jul 16 14:06:39 2008 From: tg at swox.com (Torbjorn Granlund) Date: Wed, 16 Jul 2008 14:06:39 +0200 Subject: GMP on mips64 ... In-Reply-To: (Erik Peterson's message of "Thu\, 3 Jul 2008 10\:55\:55 -0700") References: Message-ID: <86r69uvxrk.fsf@king.swox.se> Erik Peterson writes: I have built gmp for mips targeting mips on a IA linux machine. The build appears fine, however the "make check" is showing test case errors bellow. Perhaps this error is due to your IA64 GNU/Linux machine's unfortunate inability to execute MIPS64 binaries? -- Torbj?rn From tg at swox.com Wed Jul 16 14:12:03 2008 From: tg at swox.com (Torbjorn Granlund) Date: Wed, 16 Jul 2008 14:12:03 +0200 Subject: GMP 4.2.2 doesn't recognize Xeon as 64 bits In-Reply-To: <20080711120306.GA23449@vin.lip.ens-lyon.fr> (Vincent Lefevre's message of "Fri\, 11 Jul 2008 14\:03\:06 +0200") References: <20080711120306.GA23449@vin.lip.ens-lyon.fr> Message-ID: <86iqv6vxik.fsf@king.swox.se> Vincent Lefevre writes: Perhaps a known problem but I haven't found it in the gmp-bugs archives. The cnfig.guess cpuid code is not general enough. It will be fixed in the next release (due out RSN). -- Torbj?rn From r.emrich at de.tecosim.com Fri Jul 18 12:55:39 2008 From: r.emrich at de.tecosim.com (Rainer Emrich) Date: Fri, 18 Jul 2008 12:55:39 +0200 Subject: gmp-4.2.2 t-printf test fails when compiled with trunk revision 137937 on i686-pc-linux-gnu Message-ID: <488076AB.9090506@de.tecosim.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 gmp_vfprintf wrong ~ fmt |%08Zd| ~ got |000 0| ~ want |00000000| ~ got_len 8 ~ ftell_len 8 ~ fread_len 8 ~ want_len 8 /bin/sh: line 4: 10698 Aborted ${dir}$tst FAIL: t-printf PASS: t-scanf PASS: t-locale ================================== 1 of 3 tests failed Please report to gmp-bugs at swox.com ================================== - -- Mit freundlichen Gr??en / Best Regards Dipl.-Ing. Rainer Emrich Dept. Manager IT/Softwareentwicklung TECOSIM Technische Simulation GmbH Ferdinand-Stuttmann-Stra?e 15 D-65428 R?sselsheim Phone +49 (0) 6142 8272-330 Fax +49 (0) 6142 8272-249 Mobile +49 (0) 163 5694920 www.tecosim.com best partner for simulation _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ TECOSIM Technische Simulation GmbH, R?sselsheim Firmensitz: Ferdinand-Stuttmann-Stra?e 15, 65428 R?sselsheim Registergericht: Amtsgericht Darmstadt, HRB 83704 Gesch?ftsf?hrer: Udo Jankowski, J?rgen Veith -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIgHar3s6elE6CYeURAntHAJ96aYutrdQY87DRbdef8Pvp8FmMTQCgijhC Jv6IuuibngF11XX/Xa54/DY= =Z2k6 -----END PGP SIGNATURE----- From wes at hawaii.edu Sat Jul 19 05:25:30 2008 From: wes at hawaii.edu (Wes Peterson) Date: Fri, 18 Jul 2008 17:25:30 -1000 Subject: Problem with import and export of integers on i-Mac Message-ID: <437B2B89-E107-4B8D-AE6E-FB64A10DED2F@hawaii.edu> I have only been using GMP for days. This is a simple thing and it seems unlikely that it would have a bug, but also the manual is simple, clear, and unambiguous. So here it is: (By the way, I am really impressed with the speed of GMP.) /* The import and export for integers don't seem to be working correctly for me. In the example program below, first I import from the array of unsigned int into the mpz_t variable m and then I display m as a string of hex digits, and the latter display does not match what I imported. In this case, I know from other work that m is wrong. Then I set the mpz_t variable n from a string ns and then export to an array of unsigned int and print the contents of the array. Again, the output doesn't match the input. I know from other work that in this case, n is correct and is incorrectly exported. The computer is an iMac with a "2.8 GHz Intel Core 2 Duo.". The other information you requested about the system is at the end of this listing. */ /* The purpose of this is simply to demonstrate what appear to me to be a couple of bugs in GMP */ #include #include mpz_t m, n; char s[1000]; unsigned long n2[64]; char ns[] = "384e34e8 bf6aee30 b1ac7eab 7bed637a eca86a52 c1531a06 64820119 b18b2527 " "3de2e362 11c6348b 6fe1eabd fafdd2af 4a31a552 f0b7abaa a6e6f564 993b6bab " "b346c4e6 ea2b6454 d1fde18d 912692a2 3d4b3d9a 9d894fc5 20f5fd69 596721b0 " "00a8223c 2a46aba7 f8b5a5b9 813ef357 20869b27 fb73bea2 6c3d65f2 89147800 " "3126a3ed b6701e42 2296ce28 3414ef01 c86952b5 665a52d6 3745c4a2 b98f2a4c " "9dc9c1b1 b101e2fa d9a6f82b a72e6ec8 d63a8837 bd958b22 023f4b24 7a7bfb59 " "a24b67e8 bab1e43a 029be540 1fd29411 11cc9cc6 92bb8913 cbffd366 fbbb2643 " "4c5e1560 a2889aaf 3e4b3d73 c39c032e e1719247 b890b99a 3138c666 4b721ad5 "; unsigned long n1[64] = { 0x384e34e8, 0xbf6aee30, 0xb1ac7eab, 0x7bed637a, 0xeca86a52, 0xc1531a06, 0x64820119, 0xb18b2527, 0x3de2e362, 0x11c6348b, 0x6fe1eabd, 0xfafdd2af, 0x4a31a552, 0xf0b7abaa, 0xa6e6f564, 0x993b6bab, 0xb346c4e6, 0xea2b6454, 0xd1fde18d, 0x912692a2, 0x3d4b3d9a, 0x9d894fc5, 0x20f5fd69, 0x596721b0, 0x00a8223c, 0x2a46aba7, 0xf8b5a5b9, 0x813ef357, 0x20869b27, 0xfb73bea2, 0x6c3d65f2, 0x89147800, 0x3126a3ed, 0xb6701e42, 0x2296ce28, 0x3414ef01, 0xc86952b5, 0x665a52d6, 0x3745c4a2, 0xb98f2a4c, 0x9dc9c1b1, 0xb101e2fa, 0xd9a6f82b, 0xa72e6ec8, 0xd63a8837, 0xbd958b22, 0x023f4b24, 0x7a7bfb59, 0xa24b67e8, 0xbab1e43a, 0x029be540, 0x1fd29411, 0x11cc9cc6, 0x92bb8913, 0xcbffd366, 0xfbbb2643, 0x4c5e1560, 0xa2889aaf, 0x3e4b3d73, 0xc39c032e, 0xe1719247, 0xb890b99a, 0x3138c666, 0x4b721ad5}; int main() { int i, j; size_t count; mpz_init(m); mpz_init(n); mpz_import(m, 64, 1, 4, -1, 0, n1); mpz_get_str(s, 16, m); printf("\ns=%s#\n", s); mpz_set_str(n, ns, 16); mpz_export(n2, &count, 1, 4, -1, 0, n); printf("count = %d\n", count); for(i = 0; i<8; i++) { for(j = 0; j<8; j++) { printf("%08x ", n2[8*i+j]); } printf("\n"); } printf("Finished\n"); } /* printed results: wes-petersons-imac:GMP wes$ ./test s=384e34e800000000bf6aee3000000000b1ac7eab000000007bed637a00000000eca86a5200000000c1531a06000000006482011900000000b18b2527000000003de2e3620000000011c6348b000000006fe1eabd00000000fafdd2af000000004a31a55200000000f0b7abaa00000000a6e6f56400000000993b6bab00000000b346c4e600000000ea2b645400000000d1fde18d00000000912692a2000000003d4b3d9a000000009d894fc50000000020f5fd6900000000596721b00000000000a8223c000000002a46aba700000000f8b5a5b900000000813ef3570000000020869b2700000000fb73bea2000000006c3d65f2000000008914780000000000# count = 64 384e34e8 b1ac7eab eca86a52 64820119 3de2e362 6fe1eabd 4a31a552 a6e6f564 b346c4e6 d1fde18d 3d4b3d9a 20f5fd69 00a8223c f8b5a5b9 20869b27 6c3d65f2 3126a3ed 2296ce28 c86952b5 3745c4a2 9dc9c1b1 d9a6f82b d63a8837 023f4b24 a24b67e8 029be540 11cc9cc6 cbffd366 4c5e1560 3e4b3d73 e1719247 3138c666 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Finished wes-petersons-imac:GMP wes$ gcc -v Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable- checking -enable-werror --prefix=/usr --mandir=/share/man --enable- languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ $/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/ lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic -- host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5465) wes-petersons-imac:GMP wes$ uname -a Darwin wes-petersons-imac.local 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386 wes-petersons-imac:gmp-4.2.2 wes$ ./config.guess core2-apple-darwin9.4.0 wes-petersons-imac:gmp-4.2.2 wes$ ./configfsf.guess i686-apple-darwin9.4.0 */ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2411 bytes Desc: not available Url : http://swox.com/list-archives/gmp-bugs/attachments/20080718/e276e386/attachment.bin From tg at swox.com Sun Jul 20 13:16:11 2008 From: tg at swox.com (Torbjorn Granlund) Date: Sun, 20 Jul 2008 13:16:11 +0200 Subject: Problem with import and export of integers on i-Mac In-Reply-To: <437B2B89-E107-4B8D-AE6E-FB64A10DED2F@hawaii.edu> (Wes Peterson's message of "Fri\, 18 Jul 2008 17\:25\:30 -1000") References: <437B2B89-E107-4B8D-AE6E-FB64A10DED2F@hawaii.edu> Message-ID: <86abgcst50.fsf@king.swox.se> Wes Peterson writes: I have only been using GMP for days. This is a simple thing and it seems unlikely that it would have a bug, but also the manual is simple, clear, and unambiguous. So here it is: You nedd to pass the proper size of "long", such as in the example in the GMP manual. No GMP bug, user error. -- Torbj?rn From tg at swox.com Mon Jul 21 15:25:45 2008 From: tg at swox.com (Torbjorn Granlund) Date: Mon, 21 Jul 2008 15:25:45 +0200 Subject: Please update configfsf.* In-Reply-To: (Paul Green's message of "Thu\, 26 Jun 2008 12\:56\:15 -0400") References: Message-ID: <86fxq3nzc6.fsf@king.swox.se> "Green, Paul" writes: I recently downloaded gmp-4.2.2 and noticed that the copies of configfsf.guess and configfsf.sub date back to early 2004. These appear to be unmodified copies of the FSF/GNU config.guess and config.sub scripts. I'm probably not the only maintainer than has submitted patches to the maintainers of the GNU scripts since 2004. I'd like to respectfully request that you download current copies of these files and make a note to periodically refresh them (perhaps as a standard part of your release cycle). See the file ftp://ftp.gnu.org/gnu/config/README for instructions on where to obtain current copies of these scripts. Thanks, will do. -- Torbj?rn From tg at swox.com Mon Jul 21 15:57:58 2008 From: tg at swox.com (Torbjorn Granlund) Date: Mon, 21 Jul 2008 15:57:58 +0200 Subject: Compiling a C program with g++ 4.3.1 yields an error about std::FILE In-Reply-To: <20080610143820.GN4728@prunille.vinc17.org> (Vincent Lefevre's message of "Tue\, 10 Jun 2008 16\:38\:20 +0200") References: <20080610072750.GC28426@prunille.vinc17.org> <20080610090632.GD4728@prunille.vinc17.org> <20080610143417.GB15009@sumost.ca> <20080610143820.GN4728@prunille.vinc17.org> Message-ID: <86bq0rnxuh.fsf@king.swox.se> Vincent Lefevre writes: On 2008-06-10 09:34:17 -0500, Steve M. Robbins wrote: > The Debian patch does use cstdio. Yes, FYI: vin:~> diff -u x86_64/include/gmp.h /usr/include/gmp.h --- x86_64/include/gmp.h 2008-02-18 13:36:05.000000000 +0100 +++ /usr/include/gmp.h 2008-04-09 09:22:56.000000000 +0200 @@ -418,9 +418,13 @@ for an inline too, so as to correctly specify "dllimport" on windows, in case the function is called rather than inlined. GCC 4.3 and above with -std=c99 or -std=gnu99 implements ISO C99 - inline semantics, unless -fgnu89-inline is used. */ + inline semantics, unless -fgnu89-inline is used. + + With GCC 4.2, `__GNUC_STDC_INLINE__' is never defined (because C99 inline + semantics are not supported), but a warning is issued in C99 mode if + `__gnu_inline__' is not used. */ #ifdef __GNUC__ -#ifdef __GNUC_STDC_INLINE__ +#if (defined __GNUC_STDC_INLINE__) || (__GNUC__ == 4 && __GNUC_MINOR__ == 2) #define __GMP_EXTERN_INLINE extern __inline__ __attribute__ ((__gnu_inline__)) #else #define __GMP_EXTERN_INLINE extern __inline__ @@ -516,6 +520,7 @@ #if defined (__cplusplus) extern "C" { +#include #ifdef _GMP_H_HAVE_FILE using std::FILE; #endif I applied this patch. -- Torbj?rn From marc.glisse at normalesup.org Mon Jul 21 16:51:23 2008 From: marc.glisse at normalesup.org (Marc Glisse) Date: Mon, 21 Jul 2008 16:51:23 +0200 (CEST) Subject: Compiling a C program with g++ 4.3.1 yields an error about std::FILE In-Reply-To: <86bq0rnxuh.fsf@king.swox.se> References: <20080610072750.GC28426@prunille.vinc17.org> <20080610090632.GD4728@prunille.vinc17.org> <20080610143417.GB15009@sumost.ca> <20080610143820.GN4728@prunille.vinc17.org> <86bq0rnxuh.fsf@king.swox.se> Message-ID: On Mon, 21 Jul 2008, Torbjorn Granlund wrote: > @@ -516,6 +520,7 @@ > > #if defined (__cplusplus) > extern "C" { > +#include > #ifdef _GMP_H_HAVE_FILE > using std::FILE; > #endif > > I applied this patch. I know debian did it this way, but could you please put the #include line one line higher? These standard files are not meant to be included in weird situations like a namespace or a non-default linkage. Besides, the "using std::FILE" should now be unconditional. cstdio is included in the line above so std::FILE must exist, but cstdio is included after the long macro check that defines _GMP_H_HAVE_FILE so it is not defined... Maybe the include line would actually be best next to the iosfwd one at the beginning of the header? Note: I am not discussing the ugliness of the solution, just trying to make the result correct. -- Marc Glisse From tg at swox.com Mon Jul 21 17:30:34 2008 From: tg at swox.com (Torbjorn Granlund) Date: Mon, 21 Jul 2008 17:30:34 +0200 Subject: Compiling a C program with g++ 4.3.1 yields an error about std::FILE In-Reply-To: (Marc Glisse's message of "Mon\, 21 Jul 2008 16\:51\:23 +0200 \(CEST\)") References: <20080610072750.GC28426@prunille.vinc17.org> <20080610090632.GD4728@prunille.vinc17.org> <20080610143417.GB15009@sumost.ca> <20080610143820.GN4728@prunille.vinc17.org> <86bq0rnxuh.fsf@king.swox.se> Message-ID: <867ibfntk5.fsf@king.swox.se> Marc Glisse writes: I know debian did it this way, but could you please put the #include line one line higher? These standard files are not meant to be included in weird situations like a namespace or a non-default linkage. Besides, the "using std::FILE" should now be unconditional. cstdio is included in the line above so std::FILE must exist, but cstdio is included after the long macro check that defines _GMP_H_HAVE_FILE so it is not defined... Maybe the include line would actually be best next to the iosfwd one at the beginning of the header? Note: I am not discussing the ugliness of the solution, just trying to make the result correct. So, this is what you're suggesting: At the beginning of the file: #if defined (__cplusplus) #include /* for std::istream, std::ostream, std::string */ #include #endif And around line 520: #if defined (__cplusplus) extern "C" { using std::FILE; #endif -- Torbj?rn From tg at swox.com Mon Jul 21 23:55:10 2008 From: tg at swox.com (Torbjorn Granlund) Date: Mon, 21 Jul 2008 23:55:10 +0200 Subject: Compiling a C program with g++ 4.3.1 yields an error about std::FILE In-Reply-To: <867ibfntk5.fsf@king.swox.se> (Torbjorn Granlund's message of "Mon\, 21 Jul 2008 17\:30\:34 +0200") References: <20080610072750.GC28426@prunille.vinc17.org> <20080610090632.GD4728@prunille.vinc17.org> <20080610143417.GB15009@sumost.ca> <20080610143820.GN4728@prunille.vinc17.org> <86bq0rnxuh.fsf@king.swox.se> <867ibfntk5.fsf@king.swox.se> Message-ID: <86fxq23nsx.fsf@king.swox.se> Torbjorn Granlund writes: Marc Glisse writes: I know debian did it this way, but could you please put the #include line one line higher? These standard files are not meant to be included in weird situations like a namespace or a non-default linkage. Besides, the "using std::FILE" should now be unconditional. cstdio is included in the line above so std::FILE must exist, but cstdio is included after the long macro check that defines _GMP_H_HAVE_FILE so it is not defined... Maybe the include line would actually be best next to the iosfwd one at the beginning of the header? Note: I am not discussing the ugliness of the solution, just trying to make the result correct. So, this is what you're suggesting: At the beginning of the file: #if defined (__cplusplus) #include /* for std::istream, std::ostream, std::string */ #include #endif And around line 520: #if defined (__cplusplus) extern "C" { using std::FILE; #endif In C, we require users to include stdio.h for getting GMP I/O function prototypes. These changes include stdio for C++. Shouldn't we require the user to include it, like in C? -- Torbj?rn From Paul.Green at stratus.com Mon Jul 21 23:43:34 2008 From: Paul.Green at stratus.com (Green, Paul) Date: Mon, 21 Jul 2008 17:43:34 -0400 Subject: Please update configfsf.* In-Reply-To: <86fxq3nzc6.fsf@king.swox.se> References: <86fxq3nzc6.fsf@king.swox.se> Message-ID: Many thanks! PG From bn5789 at att.com Tue Jul 22 06:48:08 2008 From: bn5789 at att.com (NOVACK, BRIAN M (ATTSI)) Date: Mon, 21 Jul 2008 23:48:08 -0500 Subject: GMP 4.2.2 wrong elf class on Solaris 9 Sparc Message-ID: <131E69B6C6621043840E132F8089DDD502A9991C@mostls1msgusr75.ITServices.sbc.com> I'm on Solaris 9 (Sun V880 sparc). gcc 3.3.2. ./configure --prefix=/usr/local/gnu --with-gnu-ld CC='gcc -m64' LDFLAGS='-L/export/home/bn5789/tmp/usr/local/lib -L/usr/local/gnu/lib' When I run make check, I get the following. I can't seem to find any docs telling me how to fix this. Please help. Thanks ---Brian gcc -m64 -O2 -m64 -mptr64 -mcpu=ultrasparc3 -o .libs/t-sub t-sub.o -L/export/home/bn5789/tmp/usr/local/lib -L/usr/local/gnu/lib ./.libs/libtests.a /usr/local/gnu/src/gmp-4.2.2/.libs/libgmp.so ../.libs/libgmp.so -R/usr/local/gnu/lib ld: warning: file ../.libs/libgmp.so: linked to /usr/local/gnu/src/gmp-4.2.2/.libs/libgmp.so: attempted multiple inclusion of file creating t-sub make[4]: Leaving directory `/appl/vbio/brian/gnu/src/gmp-4.2.2/tests' make check-TESTS make[4]: Entering directory `/appl/vbio/brian/gnu/src/gmp-4.2.2/tests' ld.so.1: t-bswap: fatal: /export/home/bn5789/tmp/usr/local/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32 FAIL: t-bswap ld.so.1: t-constants: fatal: /export/home/bn5789/tmp/usr/local/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32 FAIL: t-constants ld.so.1: t-count_zeros: fatal: /export/home/bn5789/tmp/usr/local/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32 FAIL: t-count_zeros ld.so.1: t-gmpmax: fatal: /export/home/bn5789/tmp/usr/local/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32 FAIL: t-gmpmax ld.so.1: t-hightomask: fatal: /export/home/bn5789/tmp/usr/local/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32 FAIL: t-hightomask ld.so.1: t-modlinv: fatal: /export/home/bn5789/tmp/usr/local/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32 FAIL: t-modlinv ld.so.1: t-popc: fatal: /export/home/bn5789/tmp/usr/local/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32 FAIL: t-popc ld.so.1: t-parity: fatal: /export/home/bn5789/tmp/usr/local/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32 FAIL: t-parity ld.so.1: t-sub: fatal: /export/home/bn5789/tmp/usr/local/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32 FAIL: t-sub ================================== 9 of 9 tests failed Please report to gmp-bugs at swox.com ================================== make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/appl/vbio/brian/gnu/src/gmp-4.2.2/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/appl/vbio/brian/gnu/src/gmp-4.2.2/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/appl/vbio/brian/gnu/src/gmp-4.2.2/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/appl/vbio/brian/gnu/src/gmp-4.2.2' make: *** [check] Error 2 From tg at swox.com Tue Jul 22 09:20:14 2008 From: tg at swox.com (Torbjorn Granlund) Date: Tue, 22 Jul 2008 09:20:14 +0200 Subject: GMP 4.2.2 wrong elf class on Solaris 9 Sparc In-Reply-To: <131E69B6C6621043840E132F8089DDD502A9991C@mostls1msgusr75.ITServices.sbc.com> (BRIAN M. NOVACK's message of "Mon\, 21 Jul 2008 23\:48\:08 -0500") References: <131E69B6C6621043840E132F8089DDD502A9991C@mostls1msgusr75.ITServices.sbc.com> Message-ID: <864p6itmfl.fsf@king.swox.se> "NOVACK, BRIAN M (ATTSI)" writes: I'm on Solaris 9 (Sun V880 sparc). gcc 3.3.2. ./configure --prefix=/usr/local/gnu --with-gnu-ld CC='gcc -m64' LDFLAGS='-L/export/home/bn5789/tmp/usr/local/lib -L/usr/local/gnu/lib' When I run make check, I get the following. I can't seem to find any docs telling me how to fix this. Please help. This is a GCC problem, not a GMP problem. Typically, it will happen to hello.c too, in 64-bit mode. I don't think there is anything the GMP maintainers can do about this. -- Torbj?rn From tg at swox.com Tue Jul 22 14:29:23 2008 From: tg at swox.com (Torbjorn Granlund) Date: Tue, 22 Jul 2008 14:29:23 +0200 Subject: Missing period in GMP PDF and HTML manuals In-Reply-To: <20080606010423.GC2194@prunille.vinc17.org> (Vincent Lefevre's message of "Fri\, 6 Jun 2008 03\:04\:23 +0200") References: <20080606010423.GC2194@prunille.vinc17.org> Message-ID: <86k5fertjw.fsf@king.swox.se> Vincent Lefevre writes: In GMP 4.2.2, the GMPpxreftop macro is incorrect for TeX. For instance, in Section 3.1 of the GMP PDF and HTML manuals: GMP is built using Libtool and an application can use that to link if desired, see GNU Libtool with no period at the end (concerning the HTML manual, this is mainly texinfo's fault IMHO). I think the bug is just that there should be a period at the end of that sentence. The macro need no change. -- Torbj?rn From vincent at vinc17.org Tue Jul 22 14:48:25 2008 From: vincent at vinc17.org (Vincent Lefevre) Date: Tue, 22 Jul 2008 14:48:25 +0200 Subject: Missing period in GMP PDF and HTML manuals In-Reply-To: <86k5fertjw.fsf@king.swox.se> References: <20080606010423.GC2194@prunille.vinc17.org> <86k5fertjw.fsf@king.swox.se> Message-ID: <20080722124825.GI23038@prunille.vinc17.org> On 2008-07-22 14:29:23 +0200, Torbjorn Granlund wrote: > Vincent Lefevre writes: > > In GMP 4.2.2, the GMPpxreftop macro is incorrect for TeX. For instance, > in Section 3.1 of the GMP PDF and HTML manuals: > > GMP is built using Libtool and an application can use that to link > if desired, see GNU Libtool > > with no period at the end (concerning the HTML manual, this is mainly > texinfo's fault IMHO). > > I think the bug is just that there should be a period at the end of > that sentence. The macro need no change. Yes, this would solve the problem. I thought this wouldn't work because texinfo automatically adds a period when generating the info file, but I've just tried and it doesn't generate a second period if there's already one. However there's a double-period problem here: 2.3 Notes for Package Builds ============================ GMP should present no great difficulties for packaging in a binary distribution. Libtool is used to build the library and `-version-info' is set appropriately, having started from `3:0:0' in GMP 3.0 (*note Library interface versions: (libtool)Versioning.). ^^^ The corresponding source: ---- Libtool is used to build the library and @samp{-version-info} is set appropriately, having started from @samp{3:0:0} in GMP 3.0 (@pxref{Versioning, Library interface versions, Library interface versions, libtool, GNU Libtool}). ---- Isn't that stupid American typography rule requires the period to be moved inside the parenthesis? -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From tg at swox.com Tue Jul 22 15:33:44 2008 From: tg at swox.com (Torbjorn Granlund) Date: Tue, 22 Jul 2008 15:33:44 +0200 Subject: Missing period in GMP PDF and HTML manuals In-Reply-To: <20080722124825.GI23038@prunille.vinc17.org> (Vincent Lefevre's message of "Tue\, 22 Jul 2008 14\:48\:25 +0200") References: <20080606010423.GC2194@prunille.vinc17.org> <86k5fertjw.fsf@king.swox.se> <20080722124825.GI23038@prunille.vinc17.org> Message-ID: <86fxq2rqkn.fsf@king.swox.se> Vincent Lefevre writes: Libtool is used to build the library and `-version-info' is set appropriately, having started from `3:0:0' in GMP 3.0 (*note Library interface versions: (libtool)Versioning.). ^^^ The corresponding source: ---- Libtool is used to build the library and @samp{-version-info} is set appropriately, having started from @samp{3:0:0} in GMP 3.0 (@pxref{Versioning, Library interface versions, Library interface versions, libtool, GNU Libtool}). ---- Isn't that stupid American typography rule requires the period to be moved inside the parenthesis? It seems to be makeinfo-specific, I get the right results with texinfo.tex. (I tried with the latest release now, not with the one in GMP; the ;latter might behave differently.) I think I will not worry too much about this. -- Torbj?rn From marc.glisse at normalesup.org Tue Jul 22 17:04:57 2008 From: marc.glisse at normalesup.org (Marc Glisse) Date: Tue, 22 Jul 2008 17:04:57 +0200 (CEST) Subject: Compiling a C program with g++ 4.3.1 yields an error about std::FILE In-Reply-To: <86fxq23nsx.fsf@king.swox.se> References: <20080610072750.GC28426@prunille.vinc17.org> <20080610090632.GD4728@prunille.vinc17.org> <20080610143417.GB15009@sumost.ca> <20080610143820.GN4728@prunille.vinc17.org> <86bq0rnxuh.fsf@king.swox.se> <867ibfntk5.fsf@king.swox.se> <86fxq23nsx.fsf@king.swox.se> Message-ID: On Mon, 21 Jul 2008, Torbjorn Granlund wrote: > So, this is what you're suggesting: > > At the beginning of the file: > > #if defined (__cplusplus) > #include /* for std::istream, std::ostream, std::string */ > #include > #endif > > And around line 520: > > #if defined (__cplusplus) > extern "C" { > using std::FILE; > #endif Yes. That would IMHO be strictly better than what you (or debian) were doing in the previous email. The "using std::FILE" could even move next to the "include cstdio" but that is just esthetics so never mind. (I don't even remember if there is a compiler that fails without this using std::FILE (only sunpro on solaris and a theoretical perfect standard compiler AFAIK) and for which this using is sufficient (size_t and va_list are also in std:: normally), but I am just going for the minimal changes) > In C, we require users to include stdio.h for getting GMP I/O function > prototypes. These changes include stdio for C++. Shouldn't we > require the user to include it, like in C? That is an other question. In previous discussions we heard many users who wanted it by default and none who didn't want it, so I guess the reasons to make it optional in C (lighter, or stdio not even implemented) are less relevant for C++ (though they could be). But again it is your choice, the meaning of my email was just that if you wanted to include cstdio by default, the best place to include it was at the beginning. (I heard someone suggest to reverse the logic by including stdio by default, even for C, unless a macro GMP_NO_STDIO was defined by the user. That could be confusing to old code that relies on the absence of stdio, but I think the idea was that people working in this kind of environment have a better idea of what they are doing than beginners on a regular windows/mac/linux PC. I have no idea, minimizing the noise on this list is not the worst criterion...) If you are in the process of doing C++ portability patches, one I find very important is the one about freefunc in gmpxx.h (use a typedef in extern "C"). There are several versions by different people on the list (it is just a couple lines), I can resend one if needed. The thing is that all the std:: mess in gmp.h is easy to work around by including the C headers (stddef.h, stdio.h, don't know which ones exactly) or some "using" directives before gmp.h, never mind the pollution of the global namespace, whereas I have to patch gmpxx.h before I can use it. -- Marc Glisse From marc.glisse at normalesup.org Tue Jul 22 17:15:35 2008 From: marc.glisse at normalesup.org (Marc Glisse) Date: Tue, 22 Jul 2008 17:15:35 +0200 (CEST) Subject: GMP 4.2.2 wrong elf class on Solaris 9 Sparc In-Reply-To: <864p6itmfl.fsf@king.swox.se> References: <131E69B6C6621043840E132F8089DDD502A9991C@mostls1msgusr75.ITServices.sbc.com> <864p6itmfl.fsf@king.swox.se> Message-ID: On Tue, 22 Jul 2008, Torbjorn Granlund wrote: > "NOVACK, BRIAN M (ATTSI)" writes: > > I'm on Solaris 9 (Sun V880 sparc). gcc 3.3.2. > > ./configure --prefix=/usr/local/gnu --with-gnu-ld CC='gcc -m64' > LDFLAGS='-L/export/home/bn5789/tmp/usr/local/lib -L/usr/local/gnu/lib' > > When I run make check, I get the following. I can't seem to find any > docs telling me how to fix this. Please help. You probably want -L...lib/sparcv9 and most importantly the corresponding -R flag (-L for compile time path, -R for run time path). > This is a GCC problem, not a GMP problem. Typically, it will happen > to hello.c too, in 64-bit mode. > > I don't think there is anything the GMP maintainers can do about this. Agreed. I wish gcc would ship with default specs that generate a useful rpath when it is not installed in /usr (obviously with an option to cancel it for people who know what they are doing). -- Marc Glisse From tg at swox.com Wed Jul 23 17:18:11 2008 From: tg at swox.com (Torbjorn Granlund) Date: Wed, 23 Jul 2008 17:18:11 +0200 Subject: Compiling a C program with g++ 4.3.1 yields an error about std::FILE In-Reply-To: (Marc Glisse's message of "Tue\, 22 Jul 2008 17\:04\:57 +0200 \(CEST\)") References: <20080610072750.GC28426@prunille.vinc17.org> <20080610090632.GD4728@prunille.vinc17.org> <20080610143417.GB15009@sumost.ca> <20080610143820.GN4728@prunille.vinc17.org> <86bq0rnxuh.fsf@king.swox.se> <867ibfntk5.fsf@king.swox.se> <86fxq23nsx.fsf@king.swox.se> Message-ID: <86sku0mxxo.fsf@king.swox.se> Marc Glisse writes: If you are in the process of doing C++ portability patches, one I find very important is the one about freefunc in gmpxx.h (use a typedef in extern "C"). There are several versions by different people on the list (it is just a couple lines), I can resend one if needed. The thing is that all the std:: mess in gmp.h is easy to work around by including the C headers (stddef.h, stdio.h, don't know which ones exactly) or some "using" directives before gmp.h, never mind the pollution of the global namespace, whereas I have to patch gmpxx.h before I can use it. I am preparing GMP 4.2.3, and if you have some safe C++ portability changes for that release, please sedn them to the list. -- Torbj?rn From bn5789 at att.com Thu Jul 24 09:54:45 2008 From: bn5789 at att.com (NOVACK, BRIAN M (ATTSI)) Date: Thu, 24 Jul 2008 02:54:45 -0500 Subject: GMP 4.2.2 wrong elf class on Solaris 9 Sparc In-Reply-To: References: <131E69B6C6621043840E132F8089DDD502A9991C@mostls1msgusr75.ITServices.sbc.com> <864p6itmfl.fsf@king.swox.se> Message-ID: <131E69B6C6621043840E132F8089DDD502A99936@mostls1msgusr75.ITServices.sbc.com> I changed it to ABI=32 and it worked: ./configure ABI=32 --with-gmp=/usr/local/gnu --prefix=/usr/local/gnu --with-gnu-ld I still had an issue with the library on the check because my GCC libraries aren't in the standard location yet as I am using a binary of GCC to build a full GCC of which gmp and mpfr are required. Adding this director to the LD_LIBRARY_PATH fixed that: export LD_LIBRARY_PATH=/export/home/brian/tmp/usr/local:$LD_LIBRARY_PATH Thanks for the help! ---Brian -----Original Message----- From: Marc Glisse [mailto:marc.glisse at normalesup.org] Sent: Tuesday, July 22, 2008 10:16 AM To: gmp-bugs at swox.com Cc: NOVACK, BRIAN M (ATTSI) Subject: Re: GMP 4.2.2 wrong elf class on Solaris 9 Sparc On Tue, 22 Jul 2008, Torbjorn Granlund wrote: > "NOVACK, BRIAN M (ATTSI)" writes: > > I'm on Solaris 9 (Sun V880 sparc). gcc 3.3.2. > > ./configure --prefix=/usr/local/gnu --with-gnu-ld CC='gcc -m64' > LDFLAGS='-L/export/home/bn5789/tmp/usr/local/lib -L/usr/local/gnu/lib' > > When I run make check, I get the following. I can't seem to find any > docs telling me how to fix this. Please help. You probably want -L...lib/sparcv9 and most importantly the corresponding -R flag (-L for compile time path, -R for run time path). > This is a GCC problem, not a GMP problem. Typically, it will happen > to hello.c too, in 64-bit mode. > > I don't think there is anything the GMP maintainers can do about this. Agreed. I wish gcc would ship with default specs that generate a useful rpath when it is not installed in /usr (obviously with an option to cancel it for people who know what they are doing). -- Marc Glisse From ccr at sciface.com Thu Jul 24 09:53:23 2008 From: ccr at sciface.com (Christopher Creutzig) Date: Thu, 24 Jul 2008 09:53:23 +0200 Subject: Missing period in GMP PDF and HTML manuals In-Reply-To: <20080722124825.GI23038@prunille.vinc17.org> References: <20080606010423.GC2194@prunille.vinc17.org> <86k5fertjw.fsf@king.swox.se> <20080722124825.GI23038@prunille.vinc17.org> Message-ID: <488834F3.8010306@sciface.com> Vincent Lefevre wrote: > Isn't that stupid American typography rule requires the period to be > moved inside the parenthesis? Not according to the Chicago Manual Of Style, 14th Ed.: 5.14 When parentheses or brackets are used to enclose an independent sentence, the period belongs inside. when enclosed matter comes at the end of an including sentence, the period should be placed outside the parentheses or brackets: [...] -- SciFace Software GmbH & Co. KG Technologiepark 11 Tel: ++49 (0)5251 1843000 D-33100 Paderborn Fax: ++49 (0)5251 1843010 Deutschland Web: www.sciface.com Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRA 2080 Ust.-ID Nr.: DE 187992139 Pers?nlich haftende Gesellschaft: SciFace Software Verwaltungsgesellschaft mbH Registergericht Paderborn HRB 2924 Gesch?ftsf?hrer: Dr. Oliver Kluge From marc.glisse at normalesup.org Thu Jul 24 16:19:34 2008 From: marc.glisse at normalesup.org (Marc Glisse) Date: Thu, 24 Jul 2008 16:19:34 +0200 (CEST) Subject: Compiling a C program with g++ 4.3.1 yields an error about std::FILE In-Reply-To: <86sku0mxxo.fsf@king.swox.se> References: <20080610072750.GC28426@prunille.vinc17.org> <20080610090632.GD4728@prunille.vinc17.org> <20080610143417.GB15009@sumost.ca> <20080610143820.GN4728@prunille.vinc17.org> <86bq0rnxuh.fsf@king.swox.se> <867ibfntk5.fsf@king.swox.se> <86fxq23nsx.fsf@king.swox.se> <86sku0mxxo.fsf@king.swox.se> Message-ID: On Wed, 23 Jul 2008, Torbjorn Granlund wrote: > Marc Glisse writes: > > If you are in the process of doing C++ portability patches, one I find > very important is the one about freefunc in gmpxx.h (use a typedef in > extern "C"). There are several versions by different people on the list > (it is just a couple lines), I can resend one if needed. The thing is that > all the std:: mess in gmp.h is easy to work around by including the C > headers (stddef.h, stdio.h, don't know which ones exactly) or some "using" > directives before gmp.h, never mind the pollution of the global namespace, > whereas I have to patch gmpxx.h before I can use it. > > I am preparing GMP 4.2.3, and if you have some safe C++ portability > changes for that release, please sedn them to the list. "safe": I am quite sure it is correct (whereas the current code isn't), it helps with sunpro, and it does not break g++-4.3. I don't have much else available here to test on... The name freefunc_t is just an exemple, it would probably be better if it was prefixed by gmp_ or something like that. The typedef could also be moved to gmp.h as it seems like a useful addition to anyone who wants to use mp_get_memory_functions, whether in C or C++, and in there it would naturally fall inside a extern "C" when compiled in C++. --- /usr/include/gmpxx.h 2008-04-09 08:42:55.000000000 +0200 +++ gmpxx.h 2008M G'-05-26 18:10:54.924190000 +0200 @@ -1291,13 +1291,15 @@ /* this is much the same as gmp_allocated_string in gmp-impl.h since gmp-impl.h is not publicly available, I redefine it here I use a different name to avoid possible clashes */ + +extern "C" typedef void (*freefunc_t) (void *, size_t); struct __gmp_alloc_cstring { char *str; __gmp_alloc_cstring(char *s) { str = s; } ~__gmp_alloc_cstring() { - void (*freefunc) (void *, size_t); + freefunc_t freefunc; mp_get_memory_functions (NULL, NULL, &freefunc); (*freefunc) (str, std::strlen(str)+1); } Good luck with the next release, -- Marc Glisse From vincent at vinc17.org Thu Jul 24 16:39:58 2008 From: vincent at vinc17.org (Vincent Lefevre) Date: Thu, 24 Jul 2008 16:39:58 +0200 Subject: Missing period in GMP PDF and HTML manuals In-Reply-To: <488834F3.8010306@sciface.com> References: <20080606010423.GC2194@prunille.vinc17.org> <86k5fertjw.fsf@king.swox.se> <20080722124825.GI23038@prunille.vinc17.org> <488834F3.8010306@sciface.com> Message-ID: <20080724143958.GE6385@prunille.vinc17.org> On 2008-07-24 09:53:23 +0200, Christopher Creutzig wrote: > Vincent Lefevre wrote: > > > Isn't that stupid American typography rule requires the period to be > > moved inside the parenthesis? > > Not according to the Chicago Manual Of Style, 14th Ed.: OK, so I've reported a bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492210 and a copy to bug-texinfo. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From tg at swox.com Thu Jul 24 17:15:34 2008 From: tg at swox.com (Torbjorn Granlund) Date: Thu, 24 Jul 2008 17:15:34 +0200 Subject: Compiling a C program with g++ 4.3.1 yields an error about std::FILE In-Reply-To: (Marc Glisse's message of "Thu\, 24 Jul 2008 16\:19\:34 +0200 \(CEST\)") References: <20080610072750.GC28426@prunille.vinc17.org> <20080610090632.GD4728@prunille.vinc17.org> <20080610143417.GB15009@sumost.ca> <20080610143820.GN4728@prunille.vinc17.org> <86bq0rnxuh.fsf@king.swox.se> <867ibfntk5.fsf@king.swox.se> <86fxq23nsx.fsf@king.swox.se> <86sku0mxxo.fsf@king.swox.se> Message-ID: <86d4l3mhyh.fsf@king.swox.se> Marc Glisse writes: "safe": I am quite sure it is correct (whereas the current code isn't), it helps with sunpro, and it does not break g++-4.3. I don't have much else available here to test on... Thanks! I put it in and wait for the next automated build. The name freefunc_t is just an exemple, it would probably be better if it was prefixed by gmp_ or something like that. The typedef could also be moved to gmp.h as it seems like a useful addition to anyone who wants to use mp_get_memory_functions, whether in C or C++, and in there it would naturally fall inside a extern "C" when compiled in C++. I'll leave it in gmpxx.h for this dot-release. Why have the freefunc_t globally in gmpxx.h, why not put it into the function, to avoid namespace pollution? A related isue with gmpxx.h: We use many short, non-prefixed variable names like "s", and "f" and "z" in gmpxx.h. If a user decides to say #define s ) before includng gmpxx.h, I think gmpxx.h will not work too well. In C, one typically uses prefixes to avoid this. Shouldn't this be done for gmpxx.h also? -- Torbj?rn From tim.vanholder at anubex.com Thu Jul 24 17:03:03 2008 From: tim.vanholder at anubex.com (Tim Van Holder) Date: Thu, 24 Jul 2008 17:03:03 +0200 Subject: Missing period in GMP PDF and HTML manuals In-Reply-To: <20080724143958.GE6385@prunille.vinc17.org> References: <20080606010423.GC2194@prunille.vinc17.org> <86k5fertjw.fsf@king.swox.se> <20080722124825.GI23038@prunille.vinc17.org> <488834F3.8010306@sciface.com> <20080724143958.GE6385@prunille.vinc17.org> Message-ID: <488899A7.9070207@anubex.com> On 2008-07-24 16:39, Vincent Lefevre wrote: > On 2008-07-24 09:53:23 +0200, Christopher Creutzig wrote: >> Vincent Lefevre wrote: >> >>> Isn't that stupid American typography rule requires the period to be >>> moved inside the parenthesis? >> Not according to the Chicago Manual Of Style, 14th Ed.: > > OK, so I've reported a bug: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492210 > > and a copy to bug-texinfo. Sorry for not butting in earlier. I always thought Info needed that period, as an "end-of-hyperlink" marker. So by changing (*note Library interface versions: (libtool)Versioning.). to (*note Library interface versions: (libtool)Versioning). you will get info to look for a node called "Versioning)" in the libtool manual (or possibly complain about an invalid node name). If that is not the case, and the second form also finds the "Versioning" node correctly, then of course the bug report is valid. Note that it is still documented behaviour regardless - the pxref doc you quote in the bug report explicitly states that for Info output it will add a period or colon. From tg at swox.com Thu Jul 24 17:37:01 2008 From: tg at swox.com (Torbjorn Granlund) Date: Thu, 24 Jul 2008 17:37:01 +0200 Subject: Bitwise logic gmpxx.h problems Message-ID: <868wvrmgyq.fsf@king.swox.se> This code snippet, #include "gmpxx.h" int main () { mpz_class x, y; x = 3; y = x & 2; y = 2 & x; y = x | 2; y = 2 | x; y = x ^ 2; y = 2 ^ x; } creates a screenful off C++ error messages. As a C++ illiterate, I don't see why. But I had some joy with this patch: *************** struct __gmp_binary_and *** 660,663 **** --- 660,681 ---- static void eval(mpz_ptr z, mpz_srcptr w, mpz_srcptr v) { mpz_and(z, w, v); } + static void eval(mpz_ptr z, mpz_srcptr w, unsigned long int i) + { + mpz_t temp; + mp_limb_t limbs[2]; + temp->_mp_d = limbs; + temp->_mp_alloc = 2; + mpz_set_ui (temp, i); + mpz_and (z, w, temp); + } + static void eval(mpz_ptr z, unsigned long int i, mpz_srcptr w) + { + mpz_t temp; + mp_limb_t limbs[2]; + temp->_mp_d = limbs; + temp->_mp_alloc = 2; + mpz_set_ui (temp, i); + mpz_and (z, temp, w); + } }; *************** struct __gmp_binary_ior *** 666,669 **** --- 684,705 ---- static void eval(mpz_ptr z, mpz_srcptr w, mpz_srcptr v) { mpz_ior(z, w, v); } + static void eval(mpz_ptr z, mpz_srcptr w, unsigned long int i) + { + mpz_t temp; + mp_limb_t limbs[2]; + temp->_mp_d = limbs; + temp->_mp_alloc = 2; + mpz_set_ui (temp, i); + mpz_ior (z, w, temp); + } + static void eval(mpz_ptr z, unsigned long int i, mpz_srcptr w) + { + mpz_t temp; + mp_limb_t limbs[2]; + temp->_mp_d = limbs; + temp->_mp_alloc = 2; + mpz_set_ui (temp, i); + mpz_ior (z, temp, w); + } }; *************** struct __gmp_binary_xor *** 672,675 **** --- 708,729 ---- static void eval(mpz_ptr z, mpz_srcptr w, mpz_srcptr v) { mpz_xor(z, w, v); } + static void eval(mpz_ptr z, mpz_srcptr w, unsigned long int i) + { + mpz_t temp; + mp_limb_t limbs[2]; + temp->_mp_d = limbs; + temp->_mp_alloc = 2; + mpz_set_ui (temp, i); + mpz_xor (z, w, temp); + } + static void eval(mpz_ptr z, unsigned long int i, mpz_srcptr w) + { + mpz_t temp; + mp_limb_t limbs[2]; + temp->_mp_d = limbs; + temp->_mp_alloc = 2; + mpz_set_ui (temp, i); + mpz_xor (z, temp, w); + } }; But then a modified test case still causes errors: int main () { mpz_class x, y; x &= 3; x |= 3; x ^= 3; } Could some C++ hacker please suggest solutions? Do you see other similar problems with gmpxx.h that we ought to fix at the same time? -- Torbj?rn From jason at njkfrudils.plus.com Thu Jul 24 18:19:37 2008 From: jason at njkfrudils.plus.com (Jason) Date: Thu, 24 Jul 2008 17:19:37 +0100 Subject: documentation a bit unclear Message-ID: <200807241719.37659.jason@njkfrudils.plus.com> -- Function: unsigned long int mpz_remove (mpz_t ROP, mpz_t OP, mpz_t F) Remove all occurrences of the factor F from OP and store the result in ROP. The return value is how many such occurrences were removed. Not entirely clear whether ROP=F^k or ROP=OP/F^k From tg at swox.com Thu Jul 24 20:26:34 2008 From: tg at swox.com (Torbjorn Granlund) Date: Thu, 24 Jul 2008 20:26:34 +0200 Subject: Bitwise logic gmpxx.h problems In-Reply-To: (Joppe Bos's message of "Thu\, 24 Jul 2008 20\:22\:05 +0200 \(MEST\)") References: <868wvrmgyq.fsf@king.swox.se> Message-ID: <86hcafqgth.fsf@king.swox.se> Joppe Bos writes: I am not an experienced C++ hacker but the problem of these compiler errors are the following lines in gmpxx.h: __GMPP_DECLARE_COMPOUND_OPERATOR(operator&=) __GMPP_DECLARE_COMPOUND_OPERATOR(operator|=) __GMPP_DECLARE_COMPOUND_OPERATOR(operator^=) __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator&=, __gmp_binary_and) __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator|=, __gmp_binary_ior) __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator^=, __gmp_binary_xor) Replacing the double PP and ZZ by single ones solves the problem. Do you base this on experiments, or on analysis from reading the code? There ought to be a reason for the ZZ variant, they are used just for bitwise ops. -- Torbj?rn From jwbos at science.uva.nl Thu Jul 24 20:22:05 2008 From: jwbos at science.uva.nl (Joppe Bos) Date: Thu, 24 Jul 2008 20:22:05 +0200 (MEST) Subject: Bitwise logic gmpxx.h problems In-Reply-To: <868wvrmgyq.fsf@king.swox.se> References: <868wvrmgyq.fsf@king.swox.se> Message-ID: I am not an experienced C++ hacker but the problem of these compiler errors are the following lines in gmpxx.h: __GMPP_DECLARE_COMPOUND_OPERATOR(operator&=) __GMPP_DECLARE_COMPOUND_OPERATOR(operator|=) __GMPP_DECLARE_COMPOUND_OPERATOR(operator^=) __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator&=, __gmp_binary_and) __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator|=, __gmp_binary_ior) __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator^=, __gmp_binary_xor) Replacing the double PP and ZZ by single ones solves the problem. Best regards, Joppe Bos On Thu, 24 Jul 2008, Torbjorn Granlund wrote: > This code snippet, > > #include "gmpxx.h" > int > main () > { > mpz_class x, y; > x = 3; > y = x & 2; > y = 2 & x; > y = x | 2; > y = 2 | x; > y = x ^ 2; > y = 2 ^ x; > } > > creates a screenful off C++ error messages. > > As a C++ illiterate, I don't see why. But I had some joy with this > patch: > > *************** struct __gmp_binary_and > *** 660,663 **** > --- 660,681 ---- > static void eval(mpz_ptr z, mpz_srcptr w, mpz_srcptr v) > { mpz_and(z, w, v); } > + static void eval(mpz_ptr z, mpz_srcptr w, unsigned long int i) > + { > + mpz_t temp; > + mp_limb_t limbs[2]; > + temp->_mp_d = limbs; > + temp->_mp_alloc = 2; > + mpz_set_ui (temp, i); > + mpz_and (z, w, temp); > + } > + static void eval(mpz_ptr z, unsigned long int i, mpz_srcptr w) > + { > + mpz_t temp; > + mp_limb_t limbs[2]; > + temp->_mp_d = limbs; > + temp->_mp_alloc = 2; > + mpz_set_ui (temp, i); > + mpz_and (z, temp, w); > + } > }; > > *************** struct __gmp_binary_ior > *** 666,669 **** > --- 684,705 ---- > static void eval(mpz_ptr z, mpz_srcptr w, mpz_srcptr v) > { mpz_ior(z, w, v); } > + static void eval(mpz_ptr z, mpz_srcptr w, unsigned long int i) > + { > + mpz_t temp; > + mp_limb_t limbs[2]; > + temp->_mp_d = limbs; > + temp->_mp_alloc = 2; > + mpz_set_ui (temp, i); > + mpz_ior (z, w, temp); > + } > + static void eval(mpz_ptr z, unsigned long int i, mpz_srcptr w) > + { > + mpz_t temp; > + mp_limb_t limbs[2]; > + temp->_mp_d = limbs; > + temp->_mp_alloc = 2; > + mpz_set_ui (temp, i); > + mpz_ior (z, temp, w); > + } > }; > > *************** struct __gmp_binary_xor > *** 672,675 **** > --- 708,729 ---- > static void eval(mpz_ptr z, mpz_srcptr w, mpz_srcptr v) > { mpz_xor(z, w, v); } > + static void eval(mpz_ptr z, mpz_srcptr w, unsigned long int i) > + { > + mpz_t temp; > + mp_limb_t limbs[2]; > + temp->_mp_d = limbs; > + temp->_mp_alloc = 2; > + mpz_set_ui (temp, i); > + mpz_xor (z, w, temp); > + } > + static void eval(mpz_ptr z, unsigned long int i, mpz_srcptr w) > + { > + mpz_t temp; > + mp_limb_t limbs[2]; > + temp->_mp_d = limbs; > + temp->_mp_alloc = 2; > + mpz_set_ui (temp, i); > + mpz_xor (z, temp, w); > + } > }; > > > But then a modified test case still causes errors: > > int > main () > { > mpz_class x, y; > x &= 3; > x |= 3; > x ^= 3; > } > > Could some C++ hacker please suggest solutions? Do you see other > similar problems with gmpxx.h that we ought to fix at the same time? > > -- > Torbj?rn > _______________________________________________ > gmp-bugs mailing list > gmp-bugs at swox.com > http://swox.com/mailman/listinfo/gmp-bugs > From jwbos at science.uva.nl Thu Jul 24 21:38:27 2008 From: jwbos at science.uva.nl (Joppe Bos) Date: Thu, 24 Jul 2008 21:38:27 +0200 (MEST) Subject: Bitwise logic gmpxx.h problems In-Reply-To: <86hcafqgth.fsf@king.swox.se> References: <868wvrmgyq.fsf@king.swox.se> <86hcafqgth.fsf@king.swox.se> Message-ID: I based this on some experiments after reading the header file. After the suggested modifications your code compiles fine; and some test I made work also ok. Compiling is done with: g++ -Wall foo.c -lgmp I never realized the ZZ variant are there for the bitwise ops: there must be a more elegant fix. Best regards, Joppe On Thu, 24 Jul 2008, Torbjorn Granlund wrote: > Joppe Bos writes: > > I am not an experienced C++ hacker but the problem of these > compiler errors are the following lines in gmpxx.h: > > __GMPP_DECLARE_COMPOUND_OPERATOR(operator&=) > __GMPP_DECLARE_COMPOUND_OPERATOR(operator|=) > __GMPP_DECLARE_COMPOUND_OPERATOR(operator^=) > > __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator&=, __gmp_binary_and) > __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator|=, __gmp_binary_ior) > __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator^=, __gmp_binary_xor) > > Replacing the double PP and ZZ by single ones solves the problem. > > Do you base this on experiments, or on analysis from reading the code? > > There ought to be a reason for the ZZ variant, they are used just for > bitwise ops. > > -- > Torbj?rn > From Emmanuel.Thome at normalesup.org Thu Jul 24 23:03:28 2008 From: Emmanuel.Thome at normalesup.org (Emmanuel =?iso-8859-1?Q?Thom=E9?=) Date: Thu, 24 Jul 2008 23:03:28 +0200 Subject: Bitwise logic gmpxx.h problems In-Reply-To: <86hcafqgth.fsf@king.swox.se> References: <868wvrmgyq.fsf@king.swox.se> <86hcafqgth.fsf@king.swox.se> Message-ID: <20080724210328.GA2988@tiramisu.loria.fr> On Thu, Jul 24, 2008 at 08:26:34PM +0200, Torbjorn Granlund wrote: > Joppe Bos writes: > > I am not an experienced C++ hacker but the problem of these > compiler errors are the following lines in gmpxx.h: > > __GMPP_DECLARE_COMPOUND_OPERATOR(operator&=) > __GMPP_DECLARE_COMPOUND_OPERATOR(operator|=) > __GMPP_DECLARE_COMPOUND_OPERATOR(operator^=) > > __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator&=, __gmp_binary_and) > __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator|=, __gmp_binary_ior) > __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator^=, __gmp_binary_xor) > > Replacing the double PP and ZZ by single ones solves the problem. > > Do you base this on experiments, or on analysis from reading the code? > > There ought to be a reason for the ZZ variant, they are used just for > bitwise ops. perhaps precisely because without the patch you applied, it was wrong to use the __GMPZ_ and _GMP_ variants ? The only difference between __GMPZZ_ and __GMPZ_ is the definition of compound operator with PODs as right-hand types (if you follow the macro maze). I _think_ that with the provided patch, it is safe to do s/ZZ/Z/ here. Or there's some hidden can of worms somewhere that I haven't seen. Can you use your cvs tree to track back these lines to their author ? E. From tg at swox.com Thu Jul 24 23:20:11 2008 From: tg at swox.com (Torbjorn Granlund) Date: Thu, 24 Jul 2008 23:20:11 +0200 Subject: Bitwise logic gmpxx.h problems In-Reply-To: <20080724210328.GA2988@tiramisu.loria.fr> ("Emmanuel =?iso-8859-1?Q?Thom=E9=22's?= message of "Thu\, 24 Jul 2008 23\:03\:28 +0200") References: <868wvrmgyq.fsf@king.swox.se> <86hcafqgth.fsf@king.swox.se> <20080724210328.GA2988@tiramisu.loria.fr> Message-ID: <86ljzrnfn8.fsf@king.swox.se> Emmanuel Thom? writes: > Do you base this on experiments, or on analysis from reading the code? > > There ought to be a reason for the ZZ variant, they are used just for > bitwise ops. perhaps precisely because without the patch you applied, it was wrong to use the __GMPZ_ and _GMP_ variants ? The only difference between __GMPZZ_ and __GMPZ_ is the definition of compound operator with PODs as right-hand types (if you follow the macro maze). POD? I _think_ that with the provided patch, it is safe to do s/ZZ/Z/ here. Or there's some hidden can of worms somewhere that I haven't seen. Can you use your cvs tree to track back these lines to their author ? As far as I can tell, these lines come from Gerardo's original version. -- Torbj?rn From Emmanuel.Thome at normalesup.org Fri Jul 25 00:30:14 2008 From: Emmanuel.Thome at normalesup.org (Emmanuel =?iso-8859-1?Q?Thom=E9?=) Date: Fri, 25 Jul 2008 00:30:14 +0200 Subject: Bitwise logic gmpxx.h problems In-Reply-To: <86ljzrnfn8.fsf@king.swox.se> References: <868wvrmgyq.fsf@king.swox.se> <86hcafqgth.fsf@king.swox.se> <20080724210328.GA2988@tiramisu.loria.fr> <86ljzrnfn8.fsf@king.swox.se> Message-ID: <20080724223014.GA4731@tiramisu.loria.fr> On Thu, Jul 24, 2008 at 11:20:11PM +0200, Torbjorn Granlund wrote: > Emmanuel Thom? writes: > > > Do you base this on experiments, or on analysis from reading the code? > > > > There ought to be a reason for the ZZ variant, they are used just for > > bitwise ops. > > perhaps precisely because without the patch you applied, it was wrong to > use the __GMPZ_ and _GMP_ variants ? The only difference between __GMPZZ_ > and __GMPZ_ is the definition of compound operator with PODs as > right-hand types (if you follow the macro maze). > > POD? plain old datatype. > I _think_ that with the provided patch, it is safe to do s/ZZ/Z/ here. Or > there's some hidden can of worms somewhere that I haven't seen. Can you > use your cvs tree to track back these lines to their author ? > > As far as I can tell, these lines come from Gerardo's original version. so maybe a word of confirmation from him would be wise ? To me, it looks ok to substitute. E. From ambarish_mitra at persistent.co.in Fri Jul 25 07:37:42 2008 From: ambarish_mitra at persistent.co.in (Ambarish Mitra) Date: Fri, 25 Jul 2008 11:07:42 +0530 Subject: GMP 4.2.2 on Solaris10 - make checks fails Message-ID: Hi, First, my environment: ====================== bash-3.00# uname -a SunOS kenobi 5.10 Generic_127127-11 sun4u sparc SUNW,Sun-Fire-280R bash-3.00# gcc -v Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix =/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) bash-3.00# /usr/ccs/bin/ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.489 Now, the error description: ============================ I am trying to install GMP 4.2.2. I did a configure, which worked without errors. The configure executed was: -bash-3.00$ ./configure --prefix=/projects/usr/local --enable-cxx Then, I did a "make", which also worked fine. Then, I did a make check, and it failed miserably. -bash-3.00$ make check make check-recursive Making check in tests Making check in . make libtests.la t-bswap t-constants t-count_zeros t-gmpmax t-hightomask t-modlinv t-popc t-parity t-sub /bin/bash ../libtool --mode=compile -DHAVE_CONFIG_H -I. -I. -I.. -I.. -O2 -m64 -mptr64 -mcpu=ultrasparc3 -c -o memory.lo memory.c mkdir .libs .... .... make check-TESTS ld.so.1: t-bswap: fatal: /usr/sfw/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32 bash: line 4: 2368 Killed ${dir}$tst FAIL: t-bswap ld.so.1: t-constants: fatal: /usr/sfw/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32 bash: line 4: 2388 Killed ${dir}$tst FAIL: t-constants .... .... ================================== 9 of 9 tests failed Please report to gmp-bugs at swox.com ================================== *** Error code 1 The following command caused the error: failed=0; all=0; xfail=0; xpass=0; skip=0; \ srcdir=.; export srcdir; \ list='t-bswap t-constants t-count_zeros t-gmpmax t-hightomask t-modlinv t-popc t-parity t-sub'; \ if test -n "$list"; then \ for tst in $list; do \ if test -f ./$tst; then dir=./; \ elif test -f $tst; then dir=; \ else dir="./"; fi; \ if ${dir}$tst; then \ all=`expr $all + 1`; \ case " " in \ *" $tst "*) \ xpass=`expr $xpass + 1`; \ failed=`expr $failed + 1`; \ echo "XPASS: $tst"; \ ;; \ *) \ echo "PASS: $tst"; \ ;; \ esac; \ elif test $? -ne 77; then \ all=`expr $all + 1`; \ case " " in \ *" $tst "*) \ xfail=`expr $xfail + 1`; \ echo "XFAIL: $tst"; \ ;; \ *) \ failed=`expr $failed + 1`; \ echo "FAIL: $tst"; \ ;; \ esac; \ else \ skip=`expr $skip + 1`; \ echo "SKIP: $tst"; \ fi; \ done; \ if test "$failed" -eq 0; then \ if test "$xfail" -eq 0; then \ banner="All $all tests passed"; \ else \ banner="All $all tests behaved as expected ($xfail expected failures)"; \ fi; \ else \ if test "$xpass" -eq 0; then \ banner="$failed of $all tests failed"; \ else \ banner="$failed of $all tests did not behave as expected ($xpass unexpected passes)"; \ fi; \ fi; \ dashes="$banner"; \ skipped=""; \ if test "$skip" -ne 0; then \ skipped="($skip tests were not run)"; \ test `echo "$skipped" | wc -c` -gt `echo "$banner" | wc -c` && \ dashes="$skipped"; \ fi; \ report=""; \ if test "$failed" -ne 0 && test -n "gmp-bugs at swox.com"; then \ report="Please report to gmp-bugs at swox.com"; \ test `echo "$report" | wc -c` -gt `echo "$banner" | wc -c` && \ dashes="$report"; \ fi; \ dashes=`echo "$dashes" | sed s/./=/g`; \ echo "$dashes"; \ echo "$banner"; \ test -n "$skipped" && echo "$skipped"; \ test -n "$report" && echo "$report"; \ echo "$dashes"; \ test "$failed" -eq 0; \ DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. From ambarish_mitra at persistent.co.in Fri Jul 25 08:51:34 2008 From: ambarish_mitra at persistent.co.in (Ambarish Mitra) Date: Fri, 25 Jul 2008 12:21:34 +0530 Subject: GMP 4.2.2 on Solaris10 - make checks fails In-Reply-To: Message-ID: Hi all, There is some progress on the following. I setup LD_LIBRARY_PATH to lookup the proper libgcc_s.so.1 file. I noticed that, if I run the ./configure *without* --enable-cxx, then the following make check works perfectly without any error. However, if we use the ./configure --enable-cxx option, then "make check" fails: ... Making check in cxx make t-assign t-binary t-cast t-constr t-headers t-istream t-locale t-misc t-ops t-ostream t-prec t-rand t-ternary t-unary /bin/bash ../../libtool --mode=link -O2 -m64 -mptr64 -mcpu=ultrasparc3 -o t-assign t-assign.o -L../../.libs ../../tests/libtests.la ../../libgmpxx.la ../../libgmp.la g++ -O2 -m64 -mptr64 -mcpu=ultrasparc3 -o .libs/t-assign -assign.o -L/projects/installers/gnu/gmp-4.2.2/.libs ../../tests/.libs/libtests.a ../../.libs/libgmpxx.so /projects/installers/gnu/gmp-4.2.2/.libs/libgmp.so /usr/sfw/lib/sparcv9/libstdc++.so -L/usr/sfw/lib/sparcv9 -lgcc_s ../../.libs/libgmp.so -Wl,-R -Wl,/projects/usr/local/lib -Wl,-R -Wl,/usr/sf w/lib/sparcv9 ld: fatal: file /usr/sfw/lib/libgcc_s.so: wrong ELF class: ELFCLASS32 ld: warning: file ../../.libs/libgmp.so: linked to /projects/installers/gnu/gmp-4.2.2/.libs/libgmp.so: attempted multiple inclusion of file ld: warning: file /usr/sfw/lib/sparcv9/libstdc++.so: attempted multiple inclusion of file ld: fatal: File processing errors. No output written to .libs/t-assign collect2: ld returned 1 exit status *** Error code 1 ... ... -bash-3.00$ ./config.guess ultrasparc3-sun-solaris2.10 bash-3.00# uname -a SunOS kenobi 5.10 Generic_127127-11 sun4u sparc SUNW,Sun-Fire-280R bash-3.00# gcc -v Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix =/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) bash-3.00# /usr/ccs/bin/ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.489 Additionally, from the o/p above, we see that the ld is giving a lot of multiple inclusion errors. Any gentle nudge in the right direction would be great. Thanks. -----Original Message----- From: Ambarish Mitra [mailto:ambarish_mitra at persistent.co.in] Sent: Friday, July 25, 2008 11:08 AM To: gmp-bugs at swox.com Subject: GMP 4.2.2 on Solaris10 - make checks fails Hi, First, my environment: ====================== bash-3.00# uname -a SunOS kenobi 5.10 Generic_127127-11 sun4u sparc SUNW,Sun-Fire-280R bash-3.00# gcc -v Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix =/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) bash-3.00# /usr/ccs/bin/ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.489 Now, the error description: ============================ I am trying to install GMP 4.2.2. I did a configure, which worked without errors. The configure executed was: -bash-3.00$ ./configure --prefix=/projects/usr/local --enable-cxx Then, I did a "make", which also worked fine. Then, I did a make check, and it failed miserably. -bash-3.00$ make check make check-recursive Making check in tests Making check in . make libtests.la t-bswap t-constants t-count_zeros t-gmpmax t-hightomask t-modlinv t-popc t-parity t-sub /bin/bash ../libtool --mode=compile -DHAVE_CONFIG_H -I. -I. -I.. -I.. -O2 -m64 -mptr64 -mcpu=ultrasparc3 -c -o memory.lo memory.c mkdir .libs .... .... make check-TESTS ld.so.1: t-bswap: fatal: /usr/sfw/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32 bash: line 4: 2368 Killed ${dir}$tst FAIL: t-bswap ld.so.1: t-constants: fatal: /usr/sfw/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32 bash: line 4: 2388 Killed ${dir}$tst FAIL: t-constants .... .... ================================== 9 of 9 tests failed Please report to gmp-bugs at swox.com ================================== *** Error code 1 The following command caused the error: failed=0; all=0; xfail=0; xpass=0; skip=0; \ srcdir=.; export srcdir; \ list='t-bswap t-constants t-count_zeros t-gmpmax t-hightomask t-modlinv t-popc t-parity t-sub'; \ if test -n "$list"; then \ for tst in $list; do \ if test -f ./$tst; then dir=./; \ elif test -f $tst; then dir=; \ else dir="./"; fi; \ if ${dir}$tst; then \ all=`expr $all + 1`; \ case " " in \ *" $tst "*) \ xpass=`expr $xpass + 1`; \ failed=`expr $failed + 1`; \ echo "XPASS: $tst"; \ ;; \ *) \ echo "PASS: $tst"; \ ;; \ esac; \ elif test $? -ne 77; then \ all=`expr $all + 1`; \ case " " in \ *" $tst "*) \ xfail=`expr $xfail + 1`; \ echo "XFAIL: $tst"; \ ;; \ *) \ failed=`expr $failed + 1`; \ echo "FAIL: $tst"; \ ;; \ esac; \ else \ skip=`expr $skip + 1`; \ echo "SKIP: $tst"; \ fi; \ done; \ if test "$failed" -eq 0; then \ if test "$xfail" -eq 0; then \ banner="All $all tests passed"; \ else \ banner="All $all tests behaved as expected ($xfail expected failures)"; \ fi; \ else \ if test "$xpass" -eq 0; then \ banner="$failed of $all tests failed"; \ else \ banner="$failed of $all tests did not behave as expected ($xpass unexpected passes)"; \ fi; \ fi; \ dashes="$banner"; \ skipped=""; \ if test "$skip" -ne 0; then \ skipped="($skip tests were not run)"; \ test `echo "$skipped" | wc -c` -gt `echo "$banner" | wc -c` && \ dashes="$skipped"; \ fi; \ report=""; \ if test "$failed" -ne 0 && test -n "gmp-bugs at swox.com"; then \ report="Please report to gmp-bugs at swox.com"; \ test `echo "$report" | wc -c` -gt `echo "$banner" | wc -c` && \ dashes="$report"; \ fi; \ dashes=`echo "$dashes" | sed s/./=/g`; \ echo "$dashes"; \ echo "$banner"; \ test -n "$skipped" && echo "$skipped"; \ test -n "$report" && echo "$report"; \ echo "$dashes"; \ test "$failed" -eq 0; \ DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. From tg at swox.com Fri Jul 25 14:11:13 2008 From: tg at swox.com (Torbjorn Granlund) Date: Fri, 25 Jul 2008 14:11:13 +0200 Subject: Compiling a C program with g++ 4.3.1 yields an error about std::FILE In-Reply-To: (Marc Glisse's message of "Thu\, 24 Jul 2008 16\:19\:34 +0200 \(CEST\)") References: <20080610072750.GC28426@prunille.vinc17.org> <20080610090632.GD4728@prunille.vinc17.org> <20080610143417.GB15009@sumost.ca> <20080610143820.GN4728@prunille.vinc17.org> <86bq0rnxuh.fsf@king.swox.se> <867ibfntk5.fsf@king.swox.se> <86fxq23nsx.fsf@king.swox.se> <86sku0mxxo.fsf@king.swox.se> Message-ID: <86wsjamae6.fsf@king.swox.se> Marc Glisse writes: "safe": I am quite sure it is correct (whereas the current code isn't), it helps with sunpro, and it does not break g++-4.3. I don't have much else available here to test on... It turns out that gcc 2.95 has problems with the new code. Yes, some of my test machines still use that old compiler. :-) The error is: gmpxx.h:1349: multiple storage classes in declaration of `__gmp_freefunc_t' At line 1349, we have this new line: extern "C" typedef void (*__gmp_freefunc_t) (void *, size_t); I'd like to make the code work with 2.95, if possible. What would a correct alternatve form for older c++ compilers be? Just dropping the 'extern "C"' seems to help with this particular gcc release. -- Torbj?rn From marc.glisse at normalesup.org Fri Jul 25 14:13:46 2008 From: marc.glisse at normalesup.org (Marc Glisse) Date: Fri, 25 Jul 2008 14:13:46 +0200 (CEST) Subject: Bitwise logic gmpxx.h problems In-Reply-To: References: <868wvrmgyq.fsf@king.swox.se> Message-ID: On Thu, 24 Jul 2008, Joppe Bos wrote: > I am not an experienced C++ hacker but the problem of these > compiler errors are the following lines in gmpxx.h: > > __GMPP_DECLARE_COMPOUND_OPERATOR(operator&=) > __GMPP_DECLARE_COMPOUND_OPERATOR(operator|=) > __GMPP_DECLARE_COMPOUND_OPERATOR(operator^=) > > __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator&=, __gmp_binary_and) > __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator|=, __gmp_binary_ior) > __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator^=, __gmp_binary_xor) > > Replacing the double PP and ZZ by single ones solves the problem. It seems mostly right, except that we now get (experimentally) operator&=(double) which silently forwards to operator&=(unsigned long). I don't really like that. I would prefer if it either generated an error (which can be achieved by separating the float/double from the other int/short/etc in the macros) or cast the double to a mpz_class (either play with the macros to do this cast, or provide yet another overload for the eval method). >> As a C++ illiterate, I don't see why. But I had some joy with this >> patch: Looks quite similar to what I posted on 2007-12-29, except that it uses the stack for the temporary object, which indeed seems much better. The repetition of the code to "create a mpz_t large enough for a unsigned long on the stack" makes it look like this could be turned into a macro. Or maybe not (people might start using it too much). But anyway a few more places (for instance mpq multiplication and wherever mpf_init2 has a constant second argument) look like they could benefit from the same kind of optimization, even though they are a bit larger. While I am looking at this code, I find it funny that there are always several versions of eval that take their arguments in various orders and have the same code, and the code is actually duplicated instead of having one version with real code and the other versions that inline-call this one with the arguments in the right order (or some macro game). It doesn't really matter though. -- Marc Glisse From marc.glisse at normalesup.org Fri Jul 25 14:37:18 2008 From: marc.glisse at normalesup.org (Marc Glisse) Date: Fri, 25 Jul 2008 14:37:18 +0200 (CEST) Subject: Compiling a C program with g++ 4.3.1 yields an error about std::FILE In-Reply-To: <86wsjamae6.fsf@king.swox.se> References: <20080610072750.GC28426@prunille.vinc17.org> <20080610090632.GD4728@prunille.vinc17.org> <20080610143417.GB15009@sumost.ca> <20080610143820.GN4728@prunille.vinc17.org> <86bq0rnxuh.fsf@king.swox.se> <867ibfntk5.fsf@king.swox.se> <86fxq23nsx.fsf@king.swox.se> <86sku0mxxo.fsf@king.swox.se> <86wsjamae6.fsf@king.swox.se> Message-ID: On Thu, 24 Jul 2008, Torbjorn Granlund wrote: > The name freefunc_t is just an exemple, it would probably be better if it > was prefixed by gmp_ or something like that. The typedef could also be > moved to gmp.h as it seems like a useful addition to anyone who wants to > use mp_get_memory_functions, whether in C or C++, and in there it would > naturally fall inside a extern "C" when compiled in C++. > > I'll leave it in gmpxx.h for this dot-release. > > Why have the freefunc_t globally in gmpxx.h, why not put it into the > function, to avoid namespace pollution? That indeed would be nice, but it is forbidden to have linkage specifications inside anything. (It was the first thing I tried :-) > A related isue with gmpxx.h: We use many short, non-prefixed variable names like > "s", and "f" and "z" in gmpxx.h. If a user decides to say > > #define s ) > > before includng gmpxx.h, I think gmpxx.h will not work too well. In > C, one typically uses prefixes to avoid this. Shouldn't this be done > for gmpxx.h also? I know libstdc++ uglifies all variable names, but only compiler implementors have this luxury (using __gmp* in gmp is already forbidden and generates warnings with some compilers). I think mostly in C++ you can consider it the user's fault if they #define short variables, although we recently had problems with solaris defining plenty of macros with just two capital letters. If noone complains, I wouldn't worry about this. > It turns out that gcc 2.95 has problems with the new code. Yes, some > of my test machines still use that old compiler. :-) I actually still have 2.72, 2.95, 3.3, 3.4, 4.0, 4.1, 4.2 and 4.3 on an other machine for test purposes so I can verify this. > The error is: > > gmpxx.h:1349: multiple storage classes in declaration of `__gmp_freefunc_t' > > At line 1349, we have this new line: > > extern "C" typedef void (*__gmp_freefunc_t) (void *, size_t); > > I'd like to make the code work with 2.95, if possible. > > What would a correct alternatve form for older c++ compilers be? Just > dropping the 'extern "C"' seems to help with this particular gcc > release. The whole point of using a typedef is so we can have the extern "C"... modifying it to: extern "C" { typedef ...; } seems to help at compile time, but then the linker gives funny messages. /usr/bin/ld: error in t-misc.o(.eh_frame); no .eh_frame_hdr table will be created. However, I think I already have this without the patch, so g++-2.95 might simply not work anymore on this system. Can you try the version with { and } on your system? -- Marc Glisse From tg at swox.com Fri Jul 25 17:15:14 2008 From: tg at swox.com (Torbjorn Granlund) Date: Fri, 25 Jul 2008 17:15:14 +0200 Subject: Compiling a C program with g++ 4.3.1 yields an error about std::FILE In-Reply-To: (Marc Glisse's message of "Fri\, 25 Jul 2008 14\:37\:18 +0200 \(CEST\)") References: <20080610072750.GC28426@prunille.vinc17.org> <20080610090632.GD4728@prunille.vinc17.org> <20080610143417.GB15009@sumost.ca> <20080610143820.GN4728@prunille.vinc17.org> <86bq0rnxuh.fsf@king.swox.se> <867ibfntk5.fsf@king.swox.se> <86fxq23nsx.fsf@king.swox.se> <86sku0mxxo.fsf@king.swox.se> <86wsjamae6.fsf@king.swox.se> Message-ID: <864p6em1vh.fsf@king.swox.se> Marc Glisse writes: > A related isue with gmpxx.h: We use many short, non-prefixed variable names like > "s", and "f" and "z" in gmpxx.h. If a user decides to say > > #define s ) > > before includng gmpxx.h, I think gmpxx.h will not work too well. In > C, one typically uses prefixes to avoid this. Shouldn't this be done > for gmpxx.h also? I know libstdc++ uglifies all variable names, but only compiler implementors have this luxury (using __gmp* in gmp is already forbidden and generates warnings with some compilers). In C, underscore-prefixed identifiera are "reserved for the implementation", and since GMP implements something, I have decided that __GMP and __gmp are OK to use. :-) I think mostly in C++ you can consider it the user's fault if they #define short variables, although we recently had problems with solaris defining plenty of macros with just two capital letters. If noone complains, I wouldn't worry about this. OK. The whole point of using a typedef is so we can have the extern "C"... modifying it to: extern "C" { typedef ...; } seems to help at compile time, but then the linker gives funny messages. Thanks, I'll try this for the next night's tests. -- Torbj?rn From tg at swox.com Fri Jul 25 17:24:53 2008 From: tg at swox.com (Torbjorn Granlund) Date: Fri, 25 Jul 2008 17:24:53 +0200 Subject: Bitwise logic gmpxx.h problems In-Reply-To: (Marc Glisse's message of "Fri\, 25 Jul 2008 14\:13\:46 +0200 \(CEST\)") References: <868wvrmgyq.fsf@king.swox.se> Message-ID: <86zlo6kmuy.fsf@king.swox.se> Marc Glisse writes: On Thu, 24 Jul 2008, Joppe Bos wrote: > I am not an experienced C++ hacker but the problem of these > compiler errors are the following lines in gmpxx.h: > > __GMPP_DECLARE_COMPOUND_OPERATOR(operator&=) > __GMPP_DECLARE_COMPOUND_OPERATOR(operator|=) > __GMPP_DECLARE_COM