Kaffe 0.10.0 on Sparc/SunOS 4.1.4

[Eran Gluska]

Same problem here.
I manually changed the kaffe/kaffevm/Makefile by adding
the objects under COMMON+= to the COMMON object list.
(Is it a gmake feature that depends on specific version?
 I have 3.62)
This solved the linking problem, but it still doesn't
run. Usage message is displayed correctly, but when a class
name is provided, the program exits immediately without
doing anything.

----------------------------------------------------------------------------
 	Eran Gluska, National Semiconductor (IC) Ltd., P.O. Box 3007,
 			Herzliya B 46104, Israel.
    Tel: 972-9-9594255  FAX: 972-9-9558322 E-MAIL: erang at taux01.nsc.com
----------------------------------------------------------------------------

> From kaffe at rufus.w3.org  Thu Apr  2 16:00:33 1998
> Resent-From: kaffe at rufus.w3.org
> Resent-Date: Thu, 2 Apr 1998 08:01:39 -0500
> Resent-Message-Id: <199804021301.IAA06207 at rufus.w3.org>
> X-Authentication-Warning: rufus.w3.org: majordom set sender to owner-kaffe at rufus.w3.org using -f
> Date: Thu, 2 Apr 1998 22:01:28 +0900
> From: Kiyo Inaba <inaba at src.ricoh.co.jp>
> To: kaffe at rufus.w3.org
> Subject: Kaffe 0.10.0 on Sparc/SunOS 4.1.4
> Sender: owner-kaffe at rufus.w3.org
> Reply-To: kaffe at rufus.w3.org
> X-Loop: kaffe at rufus.w3.org
> X-Mailing-List: kaffe at rufus.w3.org
> Content-Length: 722
> 
> Yesterday, I got kaffe-0.10.0 and tried to compile it on
> Sparc/SunOS 4.1.4 with "gcc/disable-staticlib/jit" configuration.
> 
> But, ld complains as
> -----------------------------------------------------------------
> gcc -g -O2  -I. -I./../kaffevm -I../../config -I./../../config -I../../include -I./../../include   -o kaffe main.o -L../kaffevm -lka
> ffevm -ldl  -lm -lc 
> collect2: ld returned 2 exit status
> ld: Undefined symbol
>    _Kaffe_ThreadInterface
>    _Kaffe_LockInterface
>    _blockInts
>    _Tspinoff
> make[2]: *** [kaffe] Error 1 (ignored)
> -----------------------------------------------------------------
> 
> Has someone already fixed this problem?
> 
> # I guess this comes from definition of use for native thread, right?
> 
> Kiyo
>