app-backup/boxbackup-0.10 compiled fine with gcc 3.4.6. After migrating to gcc 4.1.1, however, the emerge fails with the following (I've just shown the tail of the build): ---- g++ -DNDEBUG -O2 -Wall -I../../lib/common -I../../lib/compress -I../../lib/crypto -I../../lib/server -I../../lib/backupclient -DBOX_VERSION="\"0.10\"" -mmmx -march=pentium2 -fomit-frame-pointer -pipe -Wall -c BackupQueries.cpp -o ../../release/bin/bbackupquery/BackupQueries.o BackupQueries.cpp: In member function 'void BackupQueries::CommandGetObject(const std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&, const bool*)': BackupQueries.cpp:818: error: 'LLONG_MIN' was not declared in this scope BackupQueries.cpp:818: error: 'LLONG_MAX' was not declared in this scope BackupQueries.cpp: In member function 'void BackupQueries::CommandGet(const std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&, const bool*)': BackupQueries.cpp:904: error: 'LLONG_MIN' was not declared in this scope BackupQueries.cpp:904: error: 'LLONG_MAX' was not declared in this scope BackupQueries.cpp: In member function 'void BackupQueries::CommandRestore(const std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&, const bool*)': BackupQueries.cpp:1697: error: 'LLONG_MIN' was not declared in this scope BackupQueries.cpp:1697: error: 'LLONG_MAX' was not declared in this scope make[1]: *** [../../release/bin/bbackupquery/BackupQueries.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/boxbackup-0.10/work/boxbackup-0.10/bin/bbackupquery' make: *** [parcels/boxbackup-0.10-backup-client-linux-gnu.tgz] Error 2 ---- Tracking this down I believe the root cause is an error during configure which is designed to determine whether the symbols LLONG_MIN and LLONG_MAX are provided by system include files or whether its own definitions need to be provided. Looking at the resulting config.log (around line 2533 - search for LLONG_MAX), it's because the configure-compiled test C program is returning "unknown unknown" for the LLONG_MIN/LLONG_MAX determined values. Looking at the test program that is shown in the config.log, and separately compiling and debugging it, the problem appears to be with the following piece of code: /* Sanity check */ if (llmin + 1 < llmin || llmin - 1 < llmin || llmax + 1 > llmax || llmax - 1 > llmax) { fprintf(f, "unknown unknown\n"); exit(2); } On gcc 3.4.6 this passes OK, but on gcc 4.1.1 the check 'fails' and causes it to exit with the status of 2 (which ultimately causes configure to build an incorrect configuration header file for the compilation stage). It seems this check falls foul of some change in gcc 4.1.1 - there aren't any compilation warnings that give any clues, unfortunately. I'm in touch with the box backup development list so can probably pass any fixes back upstream, but I'm unsure as to what the fix might be in this case.
Forgot to mention, here's my "emerge --info": Gentoo Base System version 1.6.14 Portage 2.0.54-r2 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.3.6-r3, 2.6.16-gentoo-r7 i686) ================================================================= System uname: 2.6.16-gentoo-r7 i686 Mobile Pentium II dev-lang/python: 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i386-pc-linux-gnu" CFLAGS="-mmmx -O2 -march=pentium2 -fomit-frame-pointer -pipe" CHOST="i386-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mmmx -O2 -march=pentium2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo http://pandemonium.tiscali.de/pub/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://gentoo.mirror.solnet.ch http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 alsa apache2 bash-completion berkdb bzip2 cli crypt dri eds esd ethereal expat fbcon gdbm gmp gpm gstreamer ipv6 isdnlog jpeg libwww mmx mp3 ncurses nls nptl ogg pam pcmcia pcre perl png pppd python readline reflection session spl ssl symlink tcpd udev usb vorbis xml xorg zlib userland_GNU kernel_linux elibc_glibc" Unset: CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS
remove -O2 from your CFLAGS and try again. gcc-4.1.x seems to be a bit too aggressive when using optimisation (and no debugging symbols) for more than just this package.
Created attachment 89263 [details] Test C program to illustrate where configure step fails
Thanks for the suggestion - I tried that but with the same effect (the effect is the same with all of the compiler flags removed as well, so that doesn't seem to be the reason). I've put some instrumentation into the 'sanity check' within that configure step in a separate test C program which I have attached. Comparing the output with the two different compiler versions gives the following: gcc 4.1.1 (this is the one the build fails on): compiled with:gcc -mmmx -march=pentium2 -fomit-frame-pointer -pipe conf.c -o conf Using system header for LLONG_MIN and LLONG_MAX llmin: -9223372036854775808 llmin + 1: -9223372036854775807 llmin - 1: 9223372036854775807 llmax: 9223372036854775807 llmax + 1: -9223372036854775808 llmax - 1: 9223372036854775806 sanity fail: (llmin - 1 < llmin) sanity fail: (llmax + 1 > llmax) sanity check failed gcc-3.4.6-r1 (with this compiler the build works): compiled with:gcc -mmmx -O2 -march=pentium2 -fomit-frame-pointer -pipe conf.c -o conf Using system header for LLONG_MIN and LLONG_MAX llmin: -9223372036854775808 llmin + 1: -9223372036854775807 llmin - 1: 9223372036854775807 llmax: 9223372036854775807 llmax + 1: -9223372036854775808 llmax - 1: 9223372036854775806 In both case the 'maths works' with the llmin/llmax values in that the wrapping occurs as expected, the difference is the behaviour of the comparison. I tried substituting the llmin/llmax variables for the constants shown above in the comparison with the same effect. I suspect that, even without optimisation, the compiler is being somewhat clever - clearly (X-1<X) is always TRUE... if you ignore wrapping. I'm going to see if I can peek into the generated code from the compiler (never done that before, so not sure how I'll go about it yet), but I thought I'd document my findings here anyway.
Without understanding the assembler too much, I played around with some simple programs like: --- #include <stdio.h> int main(void) { int i=1; if (i - 1 < i) { printf("yes"); } return 0; } --- On GCC 4.1 this produced the same assembler output whether or not I commented out the if statement - it was being optimised away to just leave the printf call (note I wasn't passing any -O options). On GCC 3.4 this produced different assembler output with and without the if statement, and the comparison operation was visible in the assembler when the if statement was present. So, I think it's clear *why* this is happening, the only question is whether it is correct. Do you have an opinion on that? The configure step in box-backup is there because some compilers don't provide LLONG_MIN/LLONG_MAX and so it determines them programmatically (adding 1 until it wraps, for example). This sanity check makes sure the determined values really are the limits of the 'long long' type. I think either gcc is being overzealous with optimisations here (not sure whether ISO C semantics state one way or the other on this), or whether the sanity check makes too many assumptions about what optimisations the compiler *won't* do.
Stuart, Thanks for your *very* extensive and exhaustive research into this issue. Really appreciated. I realise my comment was way too simplistic for the problem you found. I'm far from a compiler expert, so I'm affraid I cannot help you in any way with this issue. If there is a patch that gets around this problem, I'm happy to apply it. I think this is a problem that should be discussed at GCC bugzilla or mailing lists to figure out what those folks think about this issue, if they haven't dealt with it already. Based on that, I think either the boxbackup code has to be changed, or GNU should fix their compiler. If GCC porting has another standpoint to this, feel free to take over the bug, I'm clearly not of any use in this issue :)
I've been pursuing this with the box backup list and I think what I'll end up with is a patch that I'll get rolled into the next upstream box backup version (beyond 0.10). There may or may not be a compiler issue here, but it seems the easiest route will be to avoid provoking the problem. I'll work that patch into an updated app-backup/box-backup ebuild and record that here, though, so hopefully we could get that applied as a app-backup/box-backup-0.10-r1 bump. Anyway, await a patch that I'll attach here when I'm done.
OK, I've written a patch and supplied that to the upstream Box Backup project and they have accepted it into their codebase (r626 in their Subversion repository, for reference). The patch removes the reliance on the LLONG_MAX and LLONG_MIN symbols and the associated configure test that tries to programmatically determine the values if the symbols aren't found (it was this determination that fell foul of a GCC 4.1 optimisation). The STL mechanism std::numeric_limits<long long>::min/max is now used instead. I have written an ebuild bump that includes this patch in addition to the Gentoo patch that is already applied (it seemed sensible to keep them separate as this patch will fall away for the next upstream version while the Gentoo one will probably remain). The new ebuild also tidies the post-install instructions displayed and includes a few notes reminding upgraders that 0.10 is not compatible with 0.09 (so clients and servers must be upgraded together). Finally, the patch bumps the version reported by the tools to "0.10-r1". I hope this updated ebuild+patch can be included in Portage. I believe that without it or an equivalent patch Box Backup people will have trouble if they upgrade to GCC 4.1. If there are any questions then just let me know. ebuild and patch file to follow on this bug.
Created attachment 89556 [details] Bumped boxbackup ebuild (boxbackup-0.10-r1.ebuild) Updated ebuild - note that the "boxbackup-0.10-gentoo.patch" it refers to is the one currently in Portage for the 0.10 ebuild.
Created attachment 89557 [details, diff] Patch to allow the build to compile with GCC 4.1 (boxbackup-0.10-noll.patch) This patch allows Box Backup compilation to succeed with GCC 4.1. I have tested it with the following GCC versions: 3.3.6 3.4.6 4.1.1 For all the above compiler tests I was using glibc-2.3.6.
Stuart, thanks for your ebuild. A few remarks: - I removed the ewarn; I felt the info there is too superfluous and unimportant to warrant a large ewarn block: that a client can't talk with the server we find out ourselves through the logs, that the server can read the old store is not a warning at all. - I removed the version-bump from the patch, as that is a Gentoo-version bump number, instead of an upstream version bump. Gentoo revisions use the same sources, so I don't like to touch the version number. - I see no need for a version bump; the patch changes nothing for users that already could compile, and those that couldn't compile, now just can compile. No need to force a recompile for <GCC4.1 users to me. Compiles on my Mac with GCC4 :) Many thanks for the patches! In portage now.
That's excellent. Thanks for committing it and explaining reasons for your changes - I'll remember those rules for the future. I'll try the updated version when it's trickled into the mirrors, then close this bug.
Yep, updated portage now confirmed as now compiling with GCC 4.1.1. Many thanks. I'm verifying and closing the bug.
Closing.
