71760 2004-11-19 07:55 0000 dev-libs/botan version bump and arch test 2004-12-09 14:36:10 0000 1 1 1 Unclassified Gentoo Linux GCC Porting unspecified x86 All RESOLVED FIXED P2 normal --- 1 genstef@gentoo.org dragonheart@gentoo.org alpha@gentoo.org amd64@gentoo.org lloyd@randombit.net mips@gentoo.org genstef@gentoo.org 2004-11-19 07:55:44 0000 Hi, The build fails with: g++ -Ibuild/include -O2 -finline-functions -march=i586 -D_REENTRANT -ansi -Wno-long-long -W -Wall -fPIC -c src/des_tab.cpp -o build/lib/des_tab.o src/des_tab.cpp:371: error: integer constant is too large for "long" type src/des_tab.cpp:371: error: integer constant is too large for "long" type src/des_tab.cpp:372: error: integer constant is too large for "long" type [..thousands of the same errors..] src/des_tab.cpp:632: error: integer constant is too large for "long" type make: *** [build/lib/des_tab.o] Error 1 A quick look in the source made me think, that its x86 <-> amd64 related: const u64bit DES::IPTAB1[256] = { 0x0000000000000000, 0x0000000200000000, 0x0000000000000002, 0x0000000200000002, but I found no solution with my limited c++-knowledge. emerge info: Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.9-gentoo-r4 i686) ================================================================= System uname: 2.6.9-gentoo-r4 i686 Intel(R) Pentium(R) 4 CPU 2.50GHz Gentoo Base System version 1.6.6 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=i586 -fomit-frame-pointer -pipe -Os" CHOST="i586-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=i586 -fomit-frame-pointer -pipe -Os" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig buildpkg ccache cvs distlocks sandbox sfperms" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="X acpi alsa arts avi bitmap-fonts bootspla cdparanoia crypt cups dga distcache divx4linux dvd dvdread edl f77 fam fbcon foomaticdb fortran gdbm gif gnome gpm gtk gtk2 hal imlib javascript jpeg kde libg++ libwww live lzo mikmod mng mozilla mpeg ncurses network nls nptl oggvorbis opengl pam pdflib perl png qt quicktime readline rtc sdl spell ssl svg svga tcpd tga tiff truetype usb wxwindows x86 xfs xine xinerama xml xml2 xmms xosd xv xvid zlib video_cards_radeon linguas_de linguas_en" lloyd@randombit.net 2004-11-19 08:03:55 0000 The configure script should be detecting that GCC 3.4 is being used and enable the workaround for this. I can't reproduce on my Gentoo machines but all are currently 3.3 still; right before the build starts you should be seeing a message like: WARNING: Enabling -fpermissive, your GCC is/may be playing dumb about long long constants in C++ Since your build line doesn't include -fpermissive, I presume the configure script could not correctly figure out what version fo GCC you are using. genstef@gentoo.org 2004-11-19 08:09:53 0000 I do not see that output in my portage logs, what do you need to debug it? Can you maybe try to installl gcc-3.4 on your gentoo machines? lloyd@randombit.net 2004-11-19 08:25:33 0000 I'm emerging 3.4.3 now, I'll check this as soon as it finishes. lloyd@randombit.net 2004-11-19 09:42:23 0000 With gcc 3.4.3, botan-1.4.3 emerges just fine for me. The configure script correctly detects that gcc 3.4 is in use and handles it. So I'm really confused, and, apparently, have no way to debug this from here. :( Could you include the output of `g++ -v`? At this point my best guess is that for some weird reason the output of your g++ doesn't match what a 'normal' 3.4.x gcc produces so it gets a false negative. A workaround would be to add --dumb-gcc to the call to configure.pl in the ebuild. This is ugly and stupid but it would work and from the perspective of a user just wanting a build, harmless. genstef@gentoo.org 2004-11-19 09:45:18 0000 g++ -v Lese Spezifikationen von /usr/lib/gcc/i586-pc-linux-gnu/3.4.3/specs Konfiguriert mit: /var/tmp/portage/gcc-3.4.3/work/gcc-3.4.3/configure --enable-version-specific-runtime-libs --prefix=/usr --bindir=/usr/i586-pc-linux-gnu/gcc-bin/3.4 --includedir=/usr/lib/gcc/i586-pc-linux-gnu/3.4.3/include --datadir=/usr/share/gcc-data/i586-pc-linux-gnu/3.4 --mandir=/usr/share/gcc-data/i586-pc-linux-gnu/3.4/man --infodir=/usr/share/gcc-data/i586-pc-linux-gnu/3.4/info --with-gxx-include-dir=/usr/lib/gcc/i586-pc-linux-gnu/3.4.3/include/g++-v3 --host=i586-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --enable-shared --enable-threads=posix --disable-multilib --disable-libgcj --enable-languages=c,c++,f77 Thread-Modell: posix gcc-Version 3.4.3 (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6) The problem here maybe is, that I changed CHOST to i586 to be able to run the binaries also on my pentium1. lloyd@randombit.net 2004-11-19 09:56:19 0000 Gah! The script looks for a match against "gcc version 3.[34]", so it thinks that "gcc-Version 3.4.3" is OK. Well, at least now I know why it's doing it. I hadn't realized that gcc would produce the -v output in different languages/formats. Stefan: if you just want to get a build without having to change anything, do LANG=en_US emerge botan This should make g++ -v produce the output in a form Botan expects and then the build will be happy. I'll probably do this in the next release. This shouldn't impact anything else since Botan doesn't do any i18n of error messages anyway. For the current ebuild, a quick fix is adding --dumb-gcc to the configure.pl flags. dragonheart@gentoo.org 2004-12-03 21:26:24 0000 --dumb-gcc added to 1.4.3 version bumped to 1.4.4 and removed dumb-gcc. Stefan can you check this version please. Any more improvements welcome. Arch testers just after a test for your architecture on the later version. This includes comprehensive src_test routine for checking. sparc people there is a bit of code in src_compile that the authors says will work with sparcv9 - can you work out a way to add this to the condition? lloyd@randombit.net 2004-12-04 09:55:19 0000 Doh. I forgot about fixing the locale problem for 1.4.4. It will be in 1.4.5. I've attached a patch to 1.4.4's configure.pl that will fix this; works for me if I set my local to de_DE or ja_JP, at least. Sorry about that. lloyd@randombit.net 2004-12-04 09:56:16 0000 Created an attachment (id=45278) A patch to Botan 1.4.4's configure.pl dragonheart@gentoo.org 2004-12-08 02:34:09 0000 Jack - patch added - thanks. Can you double check my logic for tm_hard and mp_asm64 is what is needed. Gustavo - I had no problems with the test route on x86. I got the same error as you on ppc and I have fixed that now. Have I done the sparc condition for module tm_hard sparc54 correctly. It was 5am when you spoke to me. Hardave - you said you wanted a mips look so here it is ;-). Hope I've done the conditionals right. arch testers - src_test should be sufficient for testing. It seems fairly comprehensive gustavoz@gentoo.org 2004-12-09 06:19:50 0000 Daniel: yeah it seems you were quite asleep, you went the wrong way from what i said for sparc :-D Actually we need to set CHOSTARCH="sparc32-v9" on ARCH_PROFILE=sparc64, that's to enable v9 (ultrasparc) optimizations on the sparc64 profile (which is 32 bit userland, hence we can't use mp_asm64 and tm_hard for that case). In the future when (if) we get a 64 bit userland i'll add the hooks for that. sparc stable. lloyd@randombit.net 2004-12-09 14:36:10 0000 Daniel - The logic for enabling the tm_hard and mp_asm64 modules looks fine. One thing that may come up is that the inline asm for the 64 bit multiply in mp_asm64 hasn't been well tested on some CPUs (I think it's been tested on ia64, ppc64, and mips64 precisely once each). They all should be perfectly OK, but if the arch testers start finding problems in the validation tests, that would be the immediate suspect. Gustavo - I know you didn't ask :), but the changes you made for sparc64 also look good. I wasn't aware that the sparc64 port was doing a 32-bit userland. 45278 2004-12-04 09:56 0000 A patch to Botan 1.4.4's configure.pl gcc_version.patch text/plain LS0tIEJvdGFuLTEuNC40L2NvbmZpZ3VyZS5wbAkyMDA0LTEyLTAyIDIzOjM4OjQ0LjAwMDAwMDAw MCAtMDUwMAorKysgQm90YW4vY29uZmlndXJlLnBsCTIwMDQtMTItMDQgMTI6NDU6MjIuMTg5MDQ0 MzY4IC0wNTAwCkBAIC04MzIsNyArODMyLDcgQEAKICAgICAjIGRpZG4ndCBnZXQgb3V0cHV0LCBh c3N1bWUgaXQncyBhIGJ1Z2d5IEdDQy4gVGhlcmUgaXMgbm8gcmVkdWN0aW9uIGluIGNvZGUKICAg ICAjIHF1YWxpdHksIGV0Yywgc28gZXZlbiBpZiB3ZSdyZSB3cm9uZyBpdCdzIG5vIGJpZyBkZWFs LgogCi0gICAgaWYoKCRnY2NfdmVyc2lvbiA9fiAvZ2NjIHZlcnNpb24gM1wuWzM0XS8pIHx8Cisg ICAgaWYoKCRnY2NfdmVyc2lvbiA9fiAvM1wuWzM0XS8pIHx8CiAgICAgICAgKCRnY2NfdmVyc2lv biA9fiAvMlwuOTVcLlswLTRdLykgfHwKICAgICAgICAoJGdjY192ZXJzaW9uIGVxICcnICYmICRe TyBlcSAnY3lnd2luJykpCiAgICAgewo=