public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: More problems compiling libgcj on HP running HPUX 10.20
  2000-04-01  0:00 More problems compiling libgcj on HP running HPUX 10.20 'David Scott Urban
@ 2000-04-01  0:00 ` Tom Tromey
  0 siblings, 0 replies; 5+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: 'David Scott Urban; +Cc: java-discuss

>>>>> ">" == 'David Scott Urban <urban@ast.lmco.com> writes:

>> 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.

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.

Tom

^ permalink raw reply	[flat|nested] 5+ messages in thread

* More problems compiling libgcj on HP running HPUX 10.20
@ 2000-04-01  0:00 'David Scott Urban
  2000-04-01  0:00 ` Tom Tromey
  0 siblings, 1 reply; 5+ messages in thread
From: 'David Scott Urban @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

In my continuing attempt to get libgcj compiled on a HP running HPUX 10.20, I 
have encountered another problem.

config line : ../libgcj/configure --prefix=/home/urban/local/hp10 
--enable-java-gc=boehm --with-as=/home/urban/local/hp10/bin/gas

gcc -v ouput : Reading specs from 
/home/urban/local/hp10/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.96/specs
gcc version 2.96 20000103 (experimental)

From a previous attempt at compiling, Tom Tromey told me not to use 
--enable-interpreter since libffi is not supported on HP.

But, I am still getting an error because of ffi.h not being found. The output 
for the compile is below:



c++ -DHAVE_CONFIG_H -I. -I../../../libgcj/libjava -I./include 
-I../../../libgcj/libjava -Iinclude -I../../../libgcj/libjava/include 
-I../../../libgcj/libjava/../boehm-gc -I./../boehm-gc -DSILENT=1 -DNO_SIGNALS=1 
-DNO_DEBUGGING=1 -DJAVA_FINALIZATION=1 
-I../../../libgcj/libjava/../compat-include -I../../../libgcj/libjava/../zlib 
-I../../../libgcj/libjava/../libffi/include -I../libffi/include -fno-rtti 
-fvtable-thunks -fsjlj-exceptions -W -Wall -D_GNU_SOURCE -g -O2 -c  -fPIC -DPIC 
../../../libgcj/libjava/java/lang/reflect/natMethod.cc -o 
java/lang/reflect/.libs/natMethod.lo
../../../libgcj/libjava/java/lang/reflect/natMethod.cc:43: ffi.h: No such file 
or directory
gmake[2]: *** [java/lang/reflect/natMethod.lo] Error 1
gmake[2]: Leaving directory 
`/tmp_mnt/home/urban/gnu_src/compile/objdir/hppa1.1-hp-hpux10.20/libjava'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory 
`/tmp_mnt/home/urban/gnu_src/compile/objdir/hppa1.1-hp-hpux10.20/libjava'
gmake: *** [all-target-libjava] Error 2

In an attempt to fix the problem myself, I wrapped the include line for ffi.h 
with as follows:

#ifdef INTERPRETER
#include <ffi.h>
#endif

But, this generated a bunch of errors for variables undefined etc. I thought 
about trying wrap the offending sections of code with the ifdef. But, I am not 
sure this would be the best approach for solving the problem given the amount of 
code in the file, natMethod.cc, that depends on ffi.h. 

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.

Any and all help or suggestions would be appreciated.

Also, has anyone thought about proting libffi to the HP?

Scott Urban


D. S. Urban   
email : urban@ast.lmco.com
-------------------------------------------------------------------------------
To be the person, you must know the person. To know the person, you must
understand the person. To understand the person, you must listen. To listen,
you must open your mind and put aside all preconceived ideas and notions.
-------------------------------------------------------------------------------
All opinions expressed are my own not that of my employer 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: More problems compiling libgcj on HP running HPUX 10.20
@ 2000-04-01  0:00 'David Scott Urban
  2000-04-01  0:00 ` Tom Tromey
  0 siblings, 1 reply; 5+ messages in thread
From: 'David Scott Urban @ 2000-04-01  0:00 UTC (permalink / raw)
  To: tromey; +Cc: java-discuss

> 
> >> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: More problems compiling libgcj on HP running HPUX 10.20
  2000-04-01  0:00 ` Tom Tromey
@ 2000-04-01  0:00   ` Anthony Green
  0 siblings, 0 replies; 5+ messages in thread
From: Anthony Green @ 2000-04-01  0:00 UTC (permalink / raw)
  To: tromey; +Cc: urban, tromey, java-discuss, libffi-discuss

Tom wrote:
> I talked to Anthony (CCd) and he said he'd be happy to give advice
> about porting libffi.

The most important thing you'll need is good documentation on the ABI.
How do function arguments get passed?  Where do you find the result?
Things like that.

> Unfortunately I'm told that the HPPA ABI is particularly nasty.

It is.  Although now that I think about it I'm not sure how much more
complex it is than the MIPS n32 ABI (which is supported).

AG

-- 
Anthony Green                                                        Red Hat
                                                       Sunnyvale, California

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: More problems compiling libgcj on HP running HPUX 10.20
  2000-04-01  0:00 'David Scott Urban
@ 2000-04-01  0:00 ` Tom Tromey
  2000-04-01  0:00   ` Anthony Green
  0 siblings, 1 reply; 5+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: 'David Scott Urban; +Cc: tromey, java-discuss, Anthony Green

>>>>> ">" == 'David Scott Urban <urban@ast.lmco.com> writes:

>> 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?

As far as I know nobody is actively working on a port.

I talked to Anthony (CCd) and he said he'd be happy to give advice
about porting libffi.  Unfortunately I'm told that the HPPA ABI is
particularly nasty.

Tom

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-01  0:00 More problems compiling libgcj on HP running HPUX 10.20 'David Scott Urban
2000-04-01  0:00 ` Tom Tromey
  -- strict thread matches above, loose matches on Subject: below --
2000-04-01  0:00 'David Scott Urban
2000-04-01  0:00 ` Tom Tromey
2000-04-01  0:00   ` Anthony Green

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).