More problems compiling libgcj on HP running HPUX 10.20

Sat Apr 1 00:00:00 GMT 2000

>> >> From a previous attempt at compiling, Tom Tromey told me not to use 
> >> --enable-interpreter since libffi is not supported on HP.
>> Boy, I don't remember that. I didn't even know there wasn't an HP
> port -- I had to look at the source today to make sure.
>> >> I am wondering if this file is absolutely needed for libgcj. If
> >> not, is there some way during the configure that would leave this
> >> file out of the compile if the interpreter is not enabled.
>
This was in the mid Nov. time period last year. I was trouble because resolve.cc 
includes ffi.h and configure in libffi stated HP platform was not supported. 
Your suggestion was to not use the --enable-interpreter flag. I just recently 
was able to get back to trying to compile libgcj on the HP when all these other 
problems cropped up.
> Here's the story: last week I wrote the remaining reflection support.
> This support includes Method.invoke, which is implemented using
> libffi. Currently this code is not conditionally built; we just
> assume that FFI exists.
>> I'd apply a patch that makes this code conditional. I think you only
> have to modify code in natMethod.cc and configure.in. The idea would
> be to make Method.invoke throw the appropriate exception when not
> implemented.
>> Of course I'd much rather check in a patch to port libffi to the HP.
>
Is anyone actively working on a port of libffi to the HP? If I were to try this, 
what would be involved in porting libffi?
Scott Urban