From: Mantis B. T. <no...@bu...> - 2016-07-20 11:33:59
|
A NOTE has been added to this issue. ====================================================================== http://bugs.bacula.org/view.php?id=2236 ====================================================================== Reported By: slaanesh Assigned To: ====================================================================== Project: Bacula Bug Reports Issue ID: 2236 Category: configure/build process Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 2016-07-20 09:39 BST Last Modified: 2016-07-20 12:33 BST ====================================================================== Summary: Unable to compile on RHEL 5 32 bit systems Description: Compilation ends with this: Compiling edit.c edit.c:353: error: integer constant is too large for 'long' type edit.c:354: error: integer constant is too large for 'long' type Compiling fnmatch.c make[1]: *** [edit.lo] Error 1 make[1]: *** Waiting for unfinished jobs.... Steps to Reproduce: Compile it on RHEL 5 32 bit. Relevant settings of the build output are here: > C Compiler: gcc 4.1.2 > C++ Compiler: /usr/bin/g++ 4.1.2 > Compiler flags: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -I/usr/include/ncurses -x c++ -fno-strict-aliasing -fno-exceptions -fno-rtti Additional Information: I would like to point out that compiling on RHEL 5 x86_64 works fine. COPR build: https://copr-be.cloud.fedoraproject.org/results/slaanesh/Bacula/epel-5-i386/00395520-bacula/build.log.gz ====================================================================== ---------------------------------------------------------------------- (0007371) kern (administrator) - 2016-07-20 12:26 http://bugs.bacula.org/view.php?id=2236#c7371 ---------------------------------------------------------------------- Something is badly messed up with Bacula's handling of the system headers. The actual value is an int64_t which should be long long int. Just by chance I happen to have a RedHat 5.? 32 bit VM, and I run into the same problem. I have looked at the system headers, and I think there must be something broken in them. It appears to me that that this is a compiler bug. The Bacula definition for that table specifies an int64_t as the size, but the compiler seems to think it is a 32 bit entity or else the compiler has __WORDSIZE set incorrectly. Bottom line: this does not appear to be a Bacula bug. ==== By the way, 7.4.3 had one "regression" it is fixed and in the Bacula repo as the one commit after 7.4.3 was released. ---------------------------------------------------------------------- (0007372) kern (administrator) - 2016-07-20 12:33 http://bugs.bacula.org/view.php?id=2236#c7372 ---------------------------------------------------------------------- Oops. I think this is my mistake. The compiler *is* "broken", but I believe that all compilers were "broken" at the time that compiler was made. The compiler requires an explicit LL on the end of the two big integer values. On "modern" compilers this is no longer necessary. I have pushed a patch to the Bacula git repository that fixes this problem. Issue History Date Modified Username Field Change ====================================================================== 2016-07-20 09:39 slaanesh New Issue 2016-07-20 12:26 kern Note Added: 0007371 2016-07-20 12:26 kern Status new => feedback 2016-07-20 12:33 kern Note Added: 0007372 ====================================================================== |