rpmgit.h prototype clashes with OpenIndiana headers
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
RPM |
Fix Committed
|
Low
|
devzero2000 |
Bug Description
Building rpm 5.4.12 on x86_64-
When building rpmgit.c, compilation fails with:
gmake[4]: Entering directory `/local/
source='rpmgit.c' object='rpmgit.lo' libtool=yes \
/bin/sh ../libtool --tag=CC --mode=compile cc -m64 -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../build -I../lib -I../lib -I../rpmdb -I../rpmio -I../misc -I../beecrypt/
libtool: compile: cc -m64 -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../build -I../lib -I../lib -I../rpmdb -I../rpmio -I../misc -I../beecrypt/
"./rpmgit.h", line 171: syntax error before or at: 0x00000008
"./rpmgit.h", line 171: warning: undefined or missing type for: void
"./rpmgit.h", line 180: syntax error before or at: 0x00000020
"./rpmgit.h", line 180: warning: undefined or missing type for: void
cc: acomp failed for rpmgit.c
gmake[4]: *** [rpmgit.lo] Error 1
gmake[4]: Leaving directory `/local/
The problem is that rpmgit.h uses very short names for some of the arguments in the function prototypes. In particular, _C and _R.
A couple of the headers on SVR4-derived systems have the bad habit of using #define with very short names, and in this case _C and _R from /usr/include/
#define _U 0x00000001 /* Upper case */
#define _L 0x00000002 /* Lower case */
#define _N 0x00000004 /* Numeral (digit) */
#define _S 0x00000008 /* Spacing character */
#define _P 0x00000010 /* Punctuation */
#define _C 0x00000020 /* Control character */
#define _B 0x00000040 /* Blank */
#define _X 0x00000080 /* heXadecimal digit */
The easy fix is to alter the function prototypes to use longer argument names that do not conflict with any of the poorly-choosen pollution in the system headers.
A potential patch is attached. Only _C and _R need to change to avoid the class, but I changed all of them to be a little longer for consistency's sake.
Changed in rpm: | |
milestone: | 5.4.12 → 5.4.13 |
Changed in rpm: | |
milestone: | 5.4.13 → 5.4.14 |
The patch looks fine for a rather mundane problem
Meanwhile, would using __C instead of _C (i.e. 2 underscores)
solve the problem? I'd like the prototypes and functions to
agree if at all possible.
Note that its not at all clear whether RPM+GIT using --with-libgit2 supportable. This is a build directly from a a git
is maintainable/
checkout with no guarantee whatsoever of API/ABI compatibility.
rpm git.c has broken several times already due to changes in the libgit2 library.