Bug 128733

Summary: Undefined types in db.h during c99 compile
Product: Red Hat Enterprise Linux 3 Reporter: Need Real Name <rlee>
Component: db4Assignee: Jeff Johnson <jbj>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: rlee
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-07-28 20:49:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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)
Gecko/20040301

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):
db4-devel-4.1.25-8

How reproducible:
Always

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

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
/usr/include/features.h).

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