Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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"

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.

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?

I'm emerging 3.4.3 now, I'll check this as soon as it finishes.

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.

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.

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.

--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?

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.

Created an attachment (id=45278) [details]
A patch to Botan 1.4.4's configure.pl

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

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.

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.