Roger Brown wrote:
> 
> With various help, thanks Andy and Michael, I have got the pthreads library
> working on mac68k NetBSD 1.3.3
> (Mac IIcx, 8meg ram, 540 HD, Sonic ethernet)
> 
> The main problems I encountered were...
> 
> syssuspend() and sigprocmask() were duplicated, so I removed the definitions
> from 'syscall.S'.

NO! Don't remove those!  If anything is wrong its a #define somewhere. 
NetBSD 1.3.X has to use special versions of these (which may not work. 
I never had a chance to test them on a 1.3.X machine. ).  On NetBSD
1.4.X you don't have to do anything special with these two functions, so
the template file can be used.

> I could not get machdep.c to compile due to a problem with
> 'machdep_sys_lseek', basically the
> redefining of the off_t __syscall(), so I split this into two files, putting
> machdep_sys_lseek()
> in it's own source file and compiled it separately.

That wasn't a redefining of off_t __syscall(), that was a declaration of
__syscall().  For some reason, if you don't put that there lseek() won't
work.  I stole the idea from the Alpha port which does the same thing.

> As commented earlier, the building of the shared library requires, in my
> case, now...
> 
> ld -x -shared -o libpthread.so.1.60 --whole-archive libpthread_pic.a
> /usr/lib/c++rt0.o  machdep_sys_lseek.o --no-whole-archive

No, you shouldn't have to do that.  This tells me your Makefile is
broken.  There are three lines in the makefile that take care of this
for you:

.if ( ${OBJECT_FMT} == "a.out" )
SOBJS += /usr/lib/c++rt0.o
.endif

However these lines won't work unless you're using the package makefile.
 I ran into this same problem when I was getting the shared library to work.

> So far, standard C applications and shared libraries work well, but some C++
> applications bomb or hang on exit.
> I'm sure a C++ compiler adds alot of code for constructing and destructing
> static objects, and also I don't know
> how they deal with unwinding exceptions, they can't really use static
> setjmp/longjmp style variables, would the C++ compiler have to know about
> pthread_setspecific? Or are C++ exceptions and pthreads a big no-no?
> 
> However, these same C++ applications work on i386 linux 2.0.30 with the same
> pthreads library. This may be down to the version of the GNU C++ compiler or
> the operating system loader.
> 
> What exactly is the role of '/usr/lib/c++rt0.o' does this handle the process
> prolog *and* epilog?

I believe man ld.so explains this some.

> NetBSD 1.3.3, g++ -v --> 'gcc version 2.7.2.2+myc2'
> Linux 2.0.30, g++ -v --> 'gcc version 2.7.2.3'
> 
> So not all that much difference there....?
> 
> Regards
> 
> Roger

	-andy