fcntl64, -D_FILE_OFFSET_BITS=64

Hi, I'm trying to compile a tiny btree library with dietlibc-0.32
on an amd64 box.
( Linux version 2.6.25.5-1.1-pae (geeko@buildhost) (gcc version 4.3.1 20080507
(prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux) )


-D_FILE_OFFSET_BITS=64
gives me ( strace output ) pread64, pwrite64 and fcntl64,
but
fcntl64(5, F_SETLKW64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=2}, ... )
gets garbled to
fcntl64(5, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0.

Is this a Bug?

FYI: I have stripped down and rebuilt a version (1.85 ) of Berkeley DB.
I don't believe in external hashing, so there is only the btree part.

Some improvements:
* no more nasty bugs.
* a magic string in the header allows filetype-subtyping.
* length of inline data encoded with 2 bytes.
* a simple locking scheme allows a *limited* form of concurrent access.
* Many readers, at most one process with write intent.
  While this process modifies cached pages, other readers may proceed.
  When the first page is evicted from the cache, the writer waits for
* detach/attach instead of close/open, lazy cache initialization.
* signals are blocked in the critical section, ^C will not leave damaged files.
  Try to avoid hitting file size limits or quota.
  No transactions, no protection against system crash, but quite convenient.
* ordered inserts, e.g. those arising from syslog or sequential scans lead to
  asymmetric page splits and a high fill factor.

API summary:

BT  *bt_open( const char *filename, int mode, int mask, const BTINFO *info );
int  bt_close( BT * ) ;

int  bt_attach(BT *t ) ;
int  bt_detach(BT *t ) ; /* allow a writer to proceed */
int  bt_sync( BT *) ;

int  bt_get( BT *, const DBT *key, DBT *data ) ;
int  bt_put( BT *, const DBT *key, const DBT *data, int nooverwrite ) ;
int  bt_del( BT *, const DBT *key ) ;

int  bt_seek( BT *, DBT *key, DBT *data ) ;
int  bt_next( BT *, DBT *key, DBT *data ) ;
int  bt_prev( BT *, DBT *key, DBT *data ) ;
int  bt_first( BT *, DBT *key, DBT *data ) ;
int  bt_last( BT *, DBT *key, DBT *data ) ;

The original API used command flags to bt_seq() instead of
separate functions ( first, last, seek, next, prev ).
Trying to abstract away the file type and its behaviour is a bad idea, isn't it?