Subject: Re: libpthread.so.1.60 on NetBSD 1.3.3
To: Andy Finnell <andyf@vei.net>
From: Roger Brown <rogerhb@xtra.co.nz>
List: port-mac68k
Date: 09/06/1999 07:43:31
It actually complains while processing machdep_sys_ftruncate, but removing
the machdep_sys_lseek fixes the problem, I believe the problem to be that
the C compiler is not correctly treating the function prototype defined
within machdep_sys_lseek as being scoped to only within that function and is
trying to carry on using that prototype outside, eg within
machdep_sys_ftruncate which immediately follows, this was why splitting it
out solved the compile problem.
As for the sysprocmask and syssuspend there are a number of #defines
terminating with 13 and 14 which are used to conditionally compile the code
in syscall.S and the template .S file.

I for myself, I think it is time to move on to 1.4.1 so at least I am using
what the majority of active developers appear to be using.

Regards

Roger

----------
>From: Andy Finnell <andyf@vei.net>
>To: Roger Brown <rogerhb@xtra.co.nz>
>Cc: Christoph Badura <bad@oreilly.de>, port-mac68k@netbsd.org
>Subject: Re: libpthread.so.1.60 on NetBSD 1.3.3
>Date: Mon, Sep 6, 1999, 1:04 am
>

>Roger Brown wrote:
>> 
>> I have just repeated the build using the 'NetBSD-current' pkgsrc on
>> 'NetBSD-1.3.3' and got the same results (can't build machdep_sys_lseek due
>> to redef of syscall and duplicated symbols sigsuspend/sigprocmask).
>
>Where is syscall being duplicated?  Look at the code; it should only be
>a declaration.  For the sigsuspend/sigprocmask look in the syscall.S and
>syscall-template.S file.  In your case ( NetBSD 1.3.X ), these two
>functions should be generated in syscall.S, but not in
>syscall-template.S.  Can you verify that this is happening ( or in fact
>no happening )?
>
>> Which version of 'pkgsrc' am I supposed to use with NetBSD 1.3.3? Or do I
>> have to move to 1.4.1?
>> 
>> Regards
>> 
>> Roger
>
>Well theoritically I wrote the m68k port of pthreads to work on 1.3.X,
>but I never tested it ( I have a 1.4 system ).  A problem could be that
>1.4 uses egcs-1.1 and not  gcc.  But then I'm just guessing.
>
> -andy