Re: all Objective-C tests failing on Solaris

[Helge Hess <hh at mdlink dot de>]

Joe Buck wrote:
> This is 19990112 on sparc-sun-solaris2.5.1.
> 
> All the Objective-C tests fail.  The problem seems to be a lack of a
> thread library.

The last time I took a look at the runtime it was heavily broken after
the move up in the directory hierachy. My conclusion was to separate it
out ..

I would love it most, if egcs would only maintain/provide the structures
also used by the compiler and leave the libobjc as a completly separate
entity. This would make it much easier to support multiple threading and
GC setups at the same time. (it could generate something like objc-gcc.h
with all the compiler dependend info).

> Undefined                       first referenced
>  symbol                             in file
> pthread_getspecific                 .../libobjc/libobjc.a(thr-posix.o)
> pthread_self                        .../libobjc/libobjc.a(thr-posix.o)
> sched_yield                         .../libobjc/libobjc.a(thr-posix.o)
> pthread_key_create                  .../libobjc/libobjc.a(thr-posix.o)
> pthread_setspecific                 .../libobjc/libobjc.a(thr-posix.o)
> pthread_create                      .../libobjc/libobjc.a(thr-posix.o)
> pthread_exit                        .../libobjc/libobjc.a(thr-posix.o)
> 
> If I add -lpthread, then I still get sched_yield undefined.
> -lpthread does, however, have a thr_yield function.

I think thr-posix is supposed to be the Solaris Posix frontend. So
sched_yield is probably a Solaris function from the thread library, you
have to link -lthread -lpthread in this setup.
I don't know how it is with the other threading backends, but the native
Solaris threading backend (thr-solaris) is broken on Solaris 2.6. It
assumes that the MT structures are only sizeof(void*) bytes long, which
isn't the case anymore. If someone is interested I can send a modified
runtime.

best regards
  Helge
--
MDlink online service center
http://www.mdlink.de