Hide Forgot
While compiling rpm, the beecrypt headers are compiled with settings from different config.h. E.g. when placing | #ifndef HAVE_LONG_LONG | # error Wrong branch | #else | # warning Good branch | #endif before the first function in beecrypt/endianess.h, the compilation of beecrypt itself succeeds (with the expected warning) but fails while compiling within the lib/ or rpmio/ directory: | $ make -C beecrypt | ... | gcc -DHAVE_CONFIG_H -I. -I. -I. -DOPTIMIZE_I686 -O3 -g -march=i386 -mcpu=i686 | -fomit-frame-pointer -c aes.c -fPIC -DPIC -o .libs/aes.lo | In file included from aes.c:31: | endianness.h:36:4: warning: #warning Good branch | | $ make -C lib | gcc -DHAVE_CONFIG_H ... -c cpio.c -MT cpio.lo -MD -MP -MF .deps/cpio.TPlo -fPIC -DPIC -o .libs/cpio.lo | In file included from ../rpmio/rpmpgp.h:16, | from ../rpmio/rpmio_internal.h:11, | from cpio.c:12: | ../beecrypt/endianness.h:34:4: #error Wrong branch Compiling same sources with different views of the system does not look like a good idea and the top-level ./configure should do similar checks like the beecrypt one to define HAVE_LONG_LONG.
Hmmm, if you're saying that beecrypt (and db and zlib and libelf) are not well integrated with rpm, you're correct. This is by design, since I'm not sure that any or all of these libraries are gonna remain in the rpm source tree forever. The quick fix is to factor the HAVE_LONG_LONG test into rpm's configure.in. The better fix IMHO is to try to improve beecrypt's autoconfigure mechanism, and remove the #ifdef from endianness.h entirely. In general, beecrypt's include files are a bit complicated for a system library API ATM. So far I've failed to convince the beecrypt maintainer of using (my) <beecrypt/types.h> generated #ifdef free mechanism. He prefers having configure artifacts like HAVE_LONG_LONG #ifdef's directly in beecrypt include files. I'm patiently waiting for a resolution, gonna mark this bug deferred until then.