In file db/dbinc/mutex.h there are defines for
__mutex_lock(a,b,c) and
__mutex_unlock(a,b,c).
Unfortunatly, for QNX640 there are conflicting QNX-defines in
/usr/qnx640/target/qnx6/usr/include/pthread.h. In QNX632 these defines are not
in the pthread-header!
So the best is I think one may
On Mar 20, 2009, at 4:30 AM, Michael Baudisch wrote:
Hi community,
when compiling the RPM sources (5.1.6 and 5.1.7) for QNX there's an
error in rpmdb/rpmdb.c (lines #48 ff.) and rpmdb/sqlite.c (lines #60
ff.), saying redifinition of u_uint32_t, previously declared in ../
db3/dh.h. It's
2009/3/19 Jeff Johnson n3...@mac.com
That's better, but there's still a fundamental flaw in what
you are attempting.
Data has endiannness, not CPU's.
Yes, but the order of the data read depends on the cpu..?
I'm not sure what you mean..
So a library for cpuinfo only provides (at
On Mar 20, 2009, at 4:47 AM, Michael Baudisch wrote:
In file db/dbinc/mutex.h there are defines for
__mutex_lock(a,b,c) and
__mutex_unlock(a,b,c).
Unfortunatly, for QNX640 there are conflicting QNX-defines in /usr/
qnx640/target/qnx6/usr/include/pthread.h. In QNX632 these defines
are not
[delete __QNXNTO__ retrofit code]
HI FOLKS OUT THERE: ANYONE USING QNX EXCEPT ME??? Sorry for screeming - hoping
anyone will hear me calling... ;-)
If there's no veto by someone, then should Jeff remove the QNX retrofit code.
As the u_uint32_t define is made in db3/db.h so there should not be
- Original Nachricht
Von: Jeff Johnson n3...@mac.com
Betreff: Re: Compilation errors for QNX640 due to __mutex_lock
On Mar 20, 2009, at 4:47 AM, Michael Baudisch wrote:
In file db/dbinc/mutex.h there are defines for
__mutex_lock(a,b,c) and
__mutex_unlock(a,b,c).
On Mar 20, 2009, at 11:08 AM, Michael Baudisch wrote:
Hmmm, I see it's a temporary workaround. The problem is really
caused as QNX introduced this conflicting define. Any idea how to
solve this in a pleasant, lasting way?
Using band-aid patches is fine imho for the forseeable future.
On Fri, Mar 20, 2009, Jeff Johnson wrote:
[...]
Note that the patch is almost certainly going to get blown away
when internal Berkeley DB is upgraded down the road. Apologies
for losing the patch in advance ;-)
If done through the correct cvs import and followed by a correct
conflict
