While compiling rpm, the beecrypt headers are compiled with settings from
E.g. when placing
| #ifndef HAVE_LONG_LONG
| # error Wrong branch
| # warning Good branch
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.