Menu
▾
▴
[Bacula-bugs] [bacula 0001930]: Impossible to compile bacula-fd on OS X
|
From: Mantis B. T. <no...@bu...> - 2012-09-17 19:40:24
|
The following issue has been CLOSED ====================================================================== http://bugs.bacula.org/view.php?id=1930 ====================================================================== Reported By: ebourgui Assigned To: marcovw ====================================================================== Project: bacula Issue ID: 1930 Category: File Daemon Reproducibility: always Severity: major Priority: normal Status: closed Resolution: won't fix Fixed in Version: ====================================================================== Date Submitted: 2012-09-11 08:00 BST Last Modified: 2012-09-17 20:40 BST ====================================================================== Summary: Impossible to compile bacula-fd on OS X Description: Launching make of bacula-fd display message: crc32.c:74:2: error: #error Either HAVE_LITTLE_ENDIAN or HAVE_BIG_ENDIAN must be defined ... Steps to Reproduce: $ ./configure --enable-client-only $ make -C platforms/osx Additional Information: Xcode 3.1.4 with SDK 10.4u ====================================================================== ---------------------------------------------------------------------- (0006486) ebourgui (reporter) - 2012-09-12 16:26 http://bugs.bacula.org/view.php?id=1930#c6486 ---------------------------------------------------------------------- To bypass the test of ENDIAN type and complete successfully the compilation of bacula-fd, I comment the next lines in src/lib/crc32.c /*#if !defined(HAVE_LITTLE_ENDIAN) && !defined(HAVE_BIG_ENDIAN) #error Either HAVE_LITTLE_ENDIAN or HAVE_BIG_ENDIAN must be defined! #endif*/ ---------------------------------------------------------------------- (0006491) marcovw (developer) - 2012-09-13 07:31 http://bugs.bacula.org/view.php?id=1930#c6491 ---------------------------------------------------------------------- Problem is understood, AC_APPLE_UNIVERSAL_BUILD is defined on this platform not little or big endian. ---------------------------------------------------------------------- (0006492) marcovw (developer) - 2012-09-13 07:47 http://bugs.bacula.org/view.php?id=1930#c6492 ---------------------------------------------------------------------- As you are building universal binaries on this old platform we cannot determine at compile time what endianness you have. As the crc32 routines are in the generic library but only used in the storage daemon it should give no problem to comment out the ifdef test as the fd binary doesn't use the wrong endianness code anyhow. As this is a old platform (which is dead for quite some time) I wonder if its worth the effort of adding runtime endianness checking. ---------------------------------------------------------------------- (0006493) ebourgui (reporter) - 2012-09-13 09:09 http://bugs.bacula.org/view.php?id=1930#c6493 ---------------------------------------------------------------------- Thanks for your response. I agree with the fact that this is a very old platform and that you shouldn't have to lose time on the problem. Maybe could you implement the next test: if "uname -p" is "powerpc" then HAVE_BIG_ENDIAN = 1 else HAVE_LITTLE_ENDIAN (case of intel processor). Regards ---------------------------------------------------------------------- (0006494) marcovw (developer) - 2012-09-13 10:01 http://bugs.bacula.org/view.php?id=1930#c6494 ---------------------------------------------------------------------- That might be possible but it kind of defeats the whole universal binary thing which just builds both versions and tags them together using some smart code as far as I understand. Maybe you can switch to non universal binaries and then it will build either ppc or intel depending on what platform you are. Then again I have 0 experience with OSX. ---------------------------------------------------------------------- (0006500) kern (administrator) - 2012-09-17 20:40 http://bugs.bacula.org/view.php?id=1930#c6500 ---------------------------------------------------------------------- As Marco says, this is a really old platform. What I suggest is that you simply patch the source code to work for you. If you can come up with a generic fix for configure.in that fixes the problem, we would be happy to receive it. The other option is to build on a newer Mac. I think the resulting .dmg file will then load and run on your PPC. Issue History Date Modified Username Field Change ====================================================================== 2012-09-11 08:00 ebourgui New Issue 2012-09-11 08:00 ebourgui File Added: config.tar 2012-09-12 16:26 ebourgui Note Added: 0006486 2012-09-13 07:30 marcovw Assigned To => marcovw 2012-09-13 07:30 marcovw Status new => assigned 2012-09-13 07:31 marcovw Note Added: 0006491 2012-09-13 07:47 marcovw Note Added: 0006492 2012-09-13 07:48 marcovw Assigned To marcovw => 2012-09-13 07:48 marcovw Status assigned => feedback 2012-09-13 09:09 ebourgui Note Added: 0006493 2012-09-13 09:09 ebourgui Status feedback => new 2012-09-13 10:01 marcovw Note Added: 0006494 2012-09-13 10:16 marcovw Assigned To => marcovw 2012-09-13 10:16 marcovw Status new => feedback 2012-09-17 20:40 kern Note Added: 0006500 2012-09-17 20:40 kern Status feedback => closed 2012-09-17 20:40 kern Resolution open => won't fix ====================================================================== |