well, i didn't want to say, that things does not make sense. it's  
just, that i didn't understand, what is a posible solution for the  
THREAD_MUTEX point.


i totally agree, that porting software to as many as possible systems  
is what portability means. there's something i've learned, which means  
the same: "no portable code exist, only code, which habe been ported".

so, qnx will be one more system, soon... and we make use of it in my  
company

-piet



Am 25.01.2008 um 00:20 schrieb Jeff Johnson:

>
> On Jan 24, 2008, at 6:12 PM, Peter Kalbus wrote:
>
>> i didn't get it, sorry.
>>
>> my patch suggested to kick out the check PTHREAD_MUTEX_DEFAULT !=  
>> PTHREAD_MUTEX_NORMAL. Bu that was only a solution to get it compiled.
>>
>> from your first answer i think i got, that rpm5 does not care about  
>> pthreads. so, i guessed, that the check is not needed. if the ckech  
>> is needed, we have to take about what that means for the qnx version.
>>
>> or do i missed some understanding?
>>
>
> No, not you. I've been hacking rpm for nearly 10 years and
> there are numerous issues that I (and noone else) knows.
>
> E.g. insque/remque are old VAX instructions. I used in rpmio
> only because it made me smile: I used to have a VAX-750
> as a personal work station.
>
> Meanwhile, I know from much experience that portability comes from
> building on as many platforms as one can stand, QNX included.
>
> So its time to look at rpm from an engineering POV and rewrite
> some of the code from a portability POV, pthreads and insque/remque
> and d_off included.
>
> Feel free to ignore (or ask) anything I say that doesn't make sense.
>
> I mumble in public a lot ...
>
> 73 de Jeff
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org