Bug 128733 - Undefined types in db.h during c99 compile
Summary: Undefined types in db.h during c99 compile
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: db4 (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-07-28 19:52 UTC by Need Real Name
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-28 20:49:23 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2004-07-28 19:52:08 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)

Description of problem:
Compiling a program that includes db.h with -std=c99 results in
compilier errors.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. echo '#include <db.h> int main () {}' > t1.c
2. gcc -std=c99 t1.c

Actual Results:  In file included from t1.c:2:
/usr/include/db.h:1639: syntax error before "u_long"
/usr/include/db.h:1650: `remove' redeclared as different kind of symbol
/usr/include/stdio.h:154: previous declaration of `remove'
/usr/include/db.h:1787: syntax error before '}' token
/usr/include/db.h:1908: syntax error before "u_long"
/usr/include/db.h:1914: `txn_begin' redeclared as different kind of symbol
/usr/include/db.h:1735: previous declaration of `txn_begin'

Expected Results:  sucessful compile

Additional info:

This 'bug' seems to be present in Fedora 1 and 2 as well.

Comment 1 Need Real Name 2004-07-28 19:56:14 UTC
The fix is to define type u_long.  However, this normally is done by
other system includes.

Comment 2 Jeff Johnson 2004-07-28 20:49:23 UTC
There is no claim that db-4.1.25 is c99 clean that I'm aware of,
particularly for your t1.c test case.

There are certainly rather easy fixes including other system
includes in t1.c.

Comment 3 Need Real Name 2004-07-29 03:57:06 UTC
Here is a more thorough answer to why this is not a bug:

BerkelyDB uses BSD environment typedefs (like u_long).

Normally, gcc/glibc _defaults_ to including BSD environments -- UNLESS
an environment/standard is specifically defined, like c99 (see

Therefore, the fix is to define _BSD_SOURCE in C99 code -- in essence
specifying that the code uses both C99 and BSD environments.

Note You need to log in before you can comment on or make changes to this bug.