On Thu, 12 Sep 1996, Ian Jackson <ijackson@???> wrote: > Philip Hazel writes ("Oops. Linux..."):
> > One minor change I made was simply to reduce an annoyance. The header
> > file for the libident library (libident/ident.h) defines the __P macro
> > for handling function prototypes. The header file for Berkeley DB (db.h)
> > calls <cdefs.h> which also defines it, and doesn't check it first
> > (libident does). This causes compiler warnings.
> >
> > I like things to compile clean, so I added code to undefine __P if it
> > was already defined, before #including <db.h> from dbhdr.h.
> >
> > The first person to try compiling on Redhat Linux got a slew of errors.
> > Turns out that in that system, <db.h>, although the same version as the
> > copy I have, does NOT call <cdefs.h> and so doesn't define __P.
> >
> This is, I think, a bug in the header files on the Linux system. I
> suggest you get it fixed, by reporting it as a bug to the appropriate
> people.
Well I've now checked the db-1.85-8.src.rpm SRPM and know what has been done.
The RedHat package of db has a patched version of db.h which changes the
include of <sys/cdefs.h> to <features.h> which has (I believe) Linux specific
bits in it, and includes <sys/cdefs.h> at the end.
But the <features.h> is protected against multiple inclusions, and it will
have already ben included by something else.
By undef'ing the __P you are breaking the trust it has that the effects if the
include have already been done.
The same would be true on systems with an intact db.h but that protect against
multiple inclusion of <sys/cdefs.h>. You will fine other systems which break
because of this.
Not that I know why RedHat did this, so I'm Cc:ing it to the rembrandt-list...
