beos-native port [Was: Re: changes to thread locking layer]

[Alan L. Batongbacal]

Patrick Tullmann wrote:
> One downside to this patch is that the beos-native thread port and the
> win32 thread ports get even farther out of date.  Though, I belive
> things should be much simpler for the beos port (as it has native
> semaphore support).

I still actively work on the beos-native thread port, so as soon as the
patch goes in, I'll bring the port up to date and submit them (finally) for
integration into the repository.

On a somewhat related note, the link for the Kaffe executable fails because
the gcc invocation works out to the following:

gcc -g -O2 -Wall -Wstrict-prototypes -o Kaffe main.o version.o .libs/KaffeS.o
-W
l,--export-dynamic  -L/usr/local/lib
../../libraries/extensions/microsoft/clib/.
libs/libmicrosoft.a ../../libraries/clib/security/.libs/libsecurity.a
../../libr
aries/clib/management/.libs/libmanagement.a
../../libraries/clib/math/.libs/libm
ath.a -lz -lz ../../libraries/clib/zip/.libs/libzip.a
../../libraries/clib/io/.l
ibs/libio.a ../../libraries/clib/net/.libs/libnet.a
../../libraries/clib/native/
.libs/libnative.a ../kaffevm/.libs/libkaffevm.a -Wl,--rpath -Wl,/usr/local/lib

Note the two "-lz" occurrences (a bug in configure.in, maybe?  I noticed
the duplicated check for ZIP_LIBS...).  The link fails because they appear
before the symbols exports by libz are referenced by libzip.a.  Appending one
more "-lz" to this command line results in a successful link.  I'd appreciate
a hint as to where to point the finger here (I'm not too conversant in the
ways of libtool).

/alan