This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCJ and $PREFIX/include revisited
- From: Tom Tromey <tromey at redhat dot com>
- To: Gerald Pfeifer <gerald at pfeifer dot com>
- Cc: java at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: 15 Dec 2003 11:07:50 -0700
- Subject: Re: GCJ and $PREFIX/include revisited
- References: <Pine.BSF.4.53.0305041319370.41531@acrux.dbai.tuwien.ac.at><87llxjki7o.fsf@fleche.redhat.com><Pine.BSF.4.58.0312142309250.76198@acrux.dbai.tuwien.ac.at>
- Reply-to: tromey at redhat dot com
>>>>> "Gerald" == Gerald Pfeifer <gerald@pfeifer.com> writes:
Gerald> I know that this is an old one, and indeed the situation has
Gerald> improved quite a bit, but still there seems work to do:
Gerald> [ installed ffi, gcj headers ]
Gerald> The c++ headers are now nicely versioned, in c++/3.4/, but the java
Gerald> headers still are put directly into $PREFIX. How about doing something
Gerald> like java/3.4 or gcj/3.4 in parallel to c++?
Gerald> (This is PR7305, and it would be really nice to fix this for
Gerald> GCC 3.4. in fact, it is, somehow, a regression against
Gerald> earlier versions of GCC.)
I set target-milestone=3.4 for it. (I haven't had much time for 3.4
bug fixes recently, but at least this way we won't forget it.)
We can easily install the headers wherever we like. However, we'd
still like g++ to search the gcj headers by default. So that
presumably means a patch to the standard include directories.
Gerald> And do we really need ffi.h and jvmpi.h there?
jvmpi.h should go somewhere, I suppose. (Our JVMPI support has always
been incomplete -- I've long wanted to disable it by default.)
For ffi.h, I think the answer depends on whether we install libffi at
all.
Tom