[kaffe] gerneral kaffe breakage (this time hp-ux)

Dalibor Topic robilad at kaffe.org
Sat Jan 17 11:43:01 PST 2004

Ciao Riccardo,

Riccardo wrote:
> Hello,
> I am sorry to announce that Dalibor's big fixing and merging effort has 
> currently quite made a disaster in kaffe build and portability. I hope 

 > make disaster
gmake: *** No rule to make target `disaster'.  Stop.

I haven't got around to fully implementing that yet, apparently ;)

> this is a temporarily situation and that the work will bring us a better 
> and more powerful kaffe in the future!

That's the idea! The road to fulfill that vision seems rocky at times, 
though, and ocassionally things seem to break down in transition ;)

> Current status with full reports is as always on
> http://homepage.mac.com/riccardo_mottola/kaffe-devel/
> or if my box is on
> http://multix.dyndns.org

Thanks for running the build tests regularly. Your effort is very 

Would it be possible for you to host the (compressed, bzip2, for 
example) build logs on your homepage?

> After the sad situation of 68k and sparc, the current victim is HP-UX. 

Looks like I got another one down, then ;) Though m68k netbsd was down 
for awhile, afaik, and sparc-solaris 9 worked for me with 1.1.3 
(actually even better than 1.1.2 or older releases, I think one or two 
less regression test failures). So not all is as bad as it seems to be 
on the debian buildd for 1.1.3, for example. ;)

> In this case it is the build that fails with the following:
> In file included from ../../../kaffe/config/parisc/hpux/md.h:19,
>                  from ../../config/md.h:1,
>                  from ../../../kaffe/kaffe/kaffevm/classMethod.h:18,
>                  from ../../../kaffe/kaffe/kaffevm/support.c:33:
> ./../../kaffe/config/parisc/sysdepCallMethod.h: In function 
> `sysdepCallMethod':
> ./../../kaffe/config/parisc/sysdepCallMethod.h:56: break statement not 
> within loop or switch
> ./../../kaffe/config/parisc/sysdepCallMethod.h:61: break statement not 
> within loop or switch
> gmake[3]: *** [support.lo] Error 1

The break statements the compiler complains about were used to exit from 
the do {}while(0) loop of the macro. I didn't think about such use of 
break[1] when I converted the code to an inline function[2], so it 
remained in there.

Anyway, thanks for the bug report, I've checked in a fix into the CVS.

dalibor topic

[1] I'd take if-else-if cascades any day, they can be factored out when 
necessary more easily.
[2] There should be refactoring tools for this.

More information about the kaffe mailing list