Pb cross-compilation with GCC-4.1
Hi, I am working with Debian Etch AMD64 and want to compile for i386 but there is a problem: after launching the compilation of GCC with dpkg-buildpackage, i receive this error: > [EMAIL PROTECTED]:~/tmp/gcc/gcc-4.1-4.1.1ds2$ tail -n 50 build.log > updating cache ./config.cache > configure: loading cache ./config.cache > checking how to run the C++ preprocessor... /home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build/./gcc/xgcc -shared-libgcc -B/home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build/./gcc -nostdinc++ -L/home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build/i486-linux-gnu/64/libstdc++-v3/src -L/home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build/i486-linux-gnu/64/libstdc++-v3/src/.libs -B/usr/i486-linux-gnu/bin/ -B/usr/i486-linux-gnu/lib/ -isystem /usr/i486-linux-gnu/include -isystem /usr/i486-linux-gnu/sys-include -m64 -E > loading cache ./config.cache within ltconfig > checking host system type... x86_64-pc-linux-gnu > checking build system type... x86_64-pc-linux-gnu > checking for objdir... .libs > checking for /home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build/./gcc/xgcc option to produce PIC... -fPIC -DPIC > checking if /home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build/./gcc/xgcc PIC flag -fPIC -DPIC works... yes > checking if /home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build/./gcc/xgcc static flag -static works... no > finding the maximum length of command line arguments... (cached) 49153 > checking if /home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build/./gcc/xgcc supports -c -o file.o... (cached) yes > checking if /home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build/./gcc/xgcc supports -fno-rtti -fno-exceptions ... yes > checking whether the linker (/home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build/./gcc/collect-ld -m elf_x86_64) supports shared libraries... > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking command to parse /home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build/./gcc/nm output... failed > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... yes > appending configuration tag "CXX" to libtool > checking for exception model to use... call frame > checking for compiler with PCH support... yes > checking for enabled PCH... yes > checking for underlying I/O to use... stdio > checking how to run the C preprocessor... /home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build/./gcc/xgcc -B/home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build/./gcc/ -B/usr/i486-linux-gnu/bin/ -B/usr/i486-linux-gnu/lib/ -isystem /usr/i486-linux-gnu/include -isystem /usr/i486-linux-gnu/sys-include -m64 -E > checking for egrep... grep -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking for C locale to use... gnu > checking for msgfmt... yes > checking libintl.h usability... yes > checking libintl.h presence... yes > checking for libintl.h... yes > checking for library containing gettext... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. > make[3]: *** [configure-target-libstdc++-v3] Error 1 > make[3]: Leaving directory `/home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build' > s=`cat status`; rm -f status; test $s -eq 0 > make[1]: Leaving directory `/home/willy/tmp/gcc/gcc-4.1-4.1.1ds2' Is there a way to solve this problem ? I hope this is the good place to post this message. Willy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pb cross-compilation with GCC-4.1
Hi, Hector Oron a écrit : Hello, 2008/7/1 Willy <[EMAIL PROTECTED]>: checking for library containing gettext... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[3]: *** [configure-target-libstdc++-v3] Error 1 make[3]: Leaving directory `/home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build' s=`cat status`; rm -f status; test $s -eq 0 make[1]: Leaving directory `/home/willy/tmp/gcc/gcc-4.1-4.1.1ds2' Could you try to install g++ package with libraries and then try again? g++ is already installed: Installed packages using synaptic: gcc-3.3-base_1:3.3.6-15_amd64.deb gcc-3.4_3.4.6-5_amd64.deb gcc-3.4-base_3.4.6-5_amd64.deb gcc-4.1_4.1.1-21_amd64.deb gcc-4.1-base_4.1.1-21_amd64.deb gcc-4.1-doc_4.1.1.nf3-1_all.deb gcc_4:4.1.1-15_amd64.deb gcc-doc_4:4.1.1.nf3_all.deb gcc-doc-base_4.1.1.nf3-1_all.deb lib32gcc1_1:4.1.1-21_amd64.deb libgcc1_1:4.1.1-21_amd64.deb g++-3.4_3.4.6-5_amd64.deb g++-4.1_4.1.1-21_amd64.deb g++_4:4.1.1-15_amd64.deb lib32stdc++6_4.1.1-21_amd64.deb libstdc++5_1:3.3.6-15_amd64.deb libstdc++6_4.1.1-21_amd64.deb libstdc++6-4.1-dev_4.1.1-21_amd64.deb libstdc++6-dev_3.4.6-5_amd64.deb libc6_2.3.6.ds1-13etch5_amd64.deb libc6-dev_2.3.6.ds1-13etch5_amd64.deb libc6-dev-i386_2.3.6.ds1-13etch5_amd64.deb libc6-i386_2.3.6.ds1-13etch5_amd64.deb Installed packages using dpkg-cross: lib64gcc1-i386-cross_4.1.1-21_all.deb libc6-amd64-i386-cross_2.3.6.ds1-13etch5_all.deb libc6-dev-amd64-i386-cross_2.3.6.ds1-13etch5_all.deb libc6-dev-i386-cross_2.3.6.ds1-13etch5_all.deb libc6-i386-cross_2.3.6.ds1-13etch5_all.deb libdb1-compat-i386-cross_2.1.3-9_all.deb linux-kernel-headers-i386-cross_2.6.18-7_all.deb Compiled packages for cross-compiling: binutils-i386-linux-gnu_2.17-3_amd64.deb binutils-i486-linux-gnu_2.17-3_amd64.deb Willy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pb cross-compilation with GCC-4.1
Hi, Hector Oron a écrit : Hello, 2008/7/1 Willy <[EMAIL PROTECTED]>: checking for library containing gettext... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[3]: *** [configure-target-libstdc++-v3] Error 1 make[3]: Leaving directory `/home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/willy/tmp/gcc/gcc-4.1-4.1.1ds2/build' s=`cat status`; rm -f status; test $s -eq 0 make[1]: Leaving directory `/home/willy/tmp/gcc/gcc-4.1-4.1.1ds2' Could you try to install g++ package with libraries and then try again? The same problem occurs when compiling GCC to produce powerpc code from AMD64: Packages installed and created with dpkg-cross lib64gcc1-powerpc-cross_4.1.1-21_all.deb libc6-dev-powerpc-cross_2.3.6.ds1-13etch5_all.deb libc6-dev-ppc64-powerpc-cross_2.3.6.ds1-13etch5_all.deb libc6-powerpc-cross_2.3.6.ds1-13etch5_all.deb libc6-ppc64-powerpc-cross_2.3.6.ds1-13etch5_all.deb libdb1-compat-powerpc-cross_2.1.3-9_all.deb linux-kernel-headers-powerpc-cross_2.6.18-7_all.deb Package created for cross-compiling: binutils-powerpc-linux-gnu_2.17-3_amd64.deb For launching compilation: $ apt-get source gcc-4.1 $ cd gcc-4.1-4.1.1ds2 $ export GCC_TARGET=powerpc $ dpkg-buildpackage -rfakeroot -b > ../gcc.build result: $ tail -n 50 ../gcc.build updating cache ./config.cache configure: loading cache ./config.cache checking how to run the C++ preprocessor... /home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build/./gcc/xgcc -shared-libgcc -B/home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build/./gcc -nostdinc++ -L/home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build/powerpc-linux-gnu/64/libstdc++-v3/src -L/home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build/powerpc-linux-gnu/64/libstdc++-v3/src/.libs -B/usr/powerpc-linux-gnu/bin/ -B/usr/powerpc-linux-gnu/lib/ -isystem /usr/powerpc-linux-gnu/include -isystem /usr/powerpc-linux-gnu/sys-include -m64 -fPIC -mstrict-align -E loading cache ./config.cache within ltconfig checking host system type... powerpc-unknown-linux-gnu checking build system type... x86_64-pc-linux-gnu checking for objdir... .libs checking for /home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build/./gcc/xgcc option to produce PIC... -fPIC -DPIC checking if /home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build/./gcc/xgcc PIC flag -fPIC -DPIC works... yes checking if /home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build/./gcc/xgcc static flag -static works... no finding the maximum length of command line arguments... (cached) 49153 checking if /home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build/./gcc/xgcc supports -c -o file.o... (cached) yes checking if /home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build/./gcc/xgcc supports -fno-rtti -fno-exceptions ... yes checking whether the linker (/home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build/./gcc/collect-ld -m elf64ppc) supports shared libraries... checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so checking command to parse /home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build/./gcc/nm output... failed checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes appending configuration tag "CXX" to libtool checking for exception model to use... call frame checking for compiler with PCH support... yes checking for enabled PCH... yes checking for underlying I/O to use... stdio checking how to run the C preprocessor... /home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build/./gcc/xgcc -B/home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build/./gcc/ -B/usr/powerpc-linux-gnu/bin/ -B/usr/powerpc-linux-gnu/lib/ -isystem /usr/powerpc-linux-gnu/include -isystem /usr/powerpc-linux-gnu/sys-include -m64 -fPIC -mstrict-align -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for C locale to use... gnu checking for msgfmt... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for library containing gettext... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[3]: *** [configure-target-libstdc++-v3] Error 1 make[3]: Leaving directory `/home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2/build' s=`cat status`; rm -f status; test $s -eq 0 make[1]: Leaving directory `/home/willy/tmp/gcc-ppc/gcc-4.1-4.1.1ds2' [EMAIL PROTECTED]:~/tmp/gcc-ppc$ Willy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Bug#228421: gcc 3.0.4 generates bad code on Debian 3.0/PARISC
Package: gcc Version: 2:3.0.4-5 Kernel: Linux hp 2.4.24-pa0 #1 Sun Jan 11 18:48:21 CET 2004 parisc unknown glibc: Version: 2.2.5-11.5 GCC 3.0.4 included in Debian 3.0 generates bad code on PARISC platform. The original apache 1.3.26 distributed in this port returns lines full of zeroes in the size field of the files between 1 and 100 MB : linux-2.4.20-wt17.tar.bz2 08-Jun-2003 11:05 0.M patch-2.4.20-to-2.4.20-wt17.bz2 08-Jun-2003 11:04 -0.0M CONTENTS-2.4.20-wt1708-Jun-2003 10:5218k ... and so on. So I have recompiled 1.3.29 from sources with gcc-3.0.4, and the problem was exactly the same. Digging through the code, I discovered that for exactly these files, apache uses a floating point representation for the size, and it calls ap_rprintf() which is sort of an sprintf(), with (size/1048576.0) as an argument, and "%4.1fM" as the format string. Replacing the format with "%4eM" gave me something interesting : linux-2.4.20-wt17.tar.bz2 08-Jun-2003 11:05 8.417643e-53M patch-2.4.20-to-2.4.20-wt17.bz2 08-Jun-2003 11:04 1.284430e-57M CONTENTS-2.4.20-wt1708-Jun-2003 10:5218k I've read the complete implementation of ap_rprintf(), and it seems correct to me. But some double arguments are passed as va_args at several places. So I thought that it could be possible that gcc does not handle this very well. Then I recompiled only util_script.c and ap_snprintf.c with gcc-3.3.2, not changing anything else, and apache now reports correct sizes : linux-2.4.20-wt17.tar.bz2 08-Jun-2003 11:05 30.1M patch-2.4.20-to-2.4.20-wt17.bz2 08-Jun-2003 11:04 7.2M CONTENTS-2.4.20-wt1708-Jun-2003 10:5218k Now I've found that it's very easy to reproduce. Consider this trivial program : #include #include main() { printf("%4.1f\n", 1.23456); } Now, test it : # gcc -O2 -o fp-test fp-test.c # ./fp-test 0.0 # gcc -O1 -o fp-test fp-test.c # ./fp-test 1.2 # gcc-3.3.2-parisc -O2 -o fp-test fp-test.c # ./fp-test 1.2 # gcc -v Reading specs from /usr/lib/gcc-lib/hppa-linux/3.0.4/specs Configured with: ../src/configure -v --enable-languages=c,c++,f77,proto,objc --prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --enable-threads=posix --with-cpp-install-dir=bin hppa-linux Thread model: posix gcc version 3.0.4 # gcc-3.3.2-parisc -v Reading specs from /usr/lib/gcc-lib/hppa1.1-hp-linux-gnu/3.3.2/specs Configured with: ../gcc-3.3.2/configure --prefix=/usr --with-gnu-ld --with-gnu-as --host=hppa1.1-hp-linux-gnu --target=hppa1.1-hp-linux-gnu --with-cpu=7100LC --enable-languages=c,c++ --disable-nls --disable-locale --enable-shared --enable-target-optspace --enable-version-specific-runtime-libs --program-suffix=-3.3.2-parisc --enable-threads Thread model: posix gcc version 3.3.2 So it seems that the work-around simply is to switch back to -O1. Unfortunately, I tried about 20 -fno-XXX with -O2 to find the culprit, but I couldn't. And I don't remember how I can dump the -O1 and -O2 equivalents. I hope I didn't forget anything. At the moment, I don't know if there are packages other than apache which have been affected by this bug. Regards, Willy
Bug#228421: gcc 3.0.4 generates bad code on Debian 3.0/PARISC
On Sun, Jan 25, 2004 at 05:36:10PM +0100, Matthias Klose wrote: > tags 228421 + woody > tags 228421 + fixed-upstream > thanks > > Well, maybe a recompilation and binary NMU for apache would suffice? recompiling apache with -O1 is enough, that's what I did here and it works. > Should the report be reassignd to apache? They should be informed of the problem, as well as any other project which uses floating point and which is compiled with -O2 on parisc. But the root of the problem lies in gcc 3.0.4 since it is OK in 3.3.2. So wouldn't it be easier to identify and backport the fix from 3.3.2 to 3.0.4 and inform all projects that they must recompile everything on parisc ? Thanks, Willy