Bugzilla Bug 136300

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 an attachment (id=89263) [edit]
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 an attachment (id=89556) [edit]
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 an attachment (id=89557) [edit]
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.