This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [PATCH] to java::lang::ConcreteProcess::destroy
- From: Tom Tromey <tromey at redhat dot com>
- To: Ronald Landheer-Cieslak <ronald at landheer dot com>
- Cc: Andrew Haley <aph at redhat dot com>, <gcc-patches at gcc dot gnu dot org>, <java-patches at gcc dot gnu dot org>
- Date: 17 Feb 2003 16:53:21 -0700
- Subject: Re: [PATCH] to java::lang::ConcreteProcess::destroy
- References: <Pine.LNX.4.44.0302171738220.27067-100000@localhost.localdomain>
- Reply-to: tromey at redhat dot com
>>>>> "Ronald" == Ronald Landheer-Cieslak <ronald@landheer.com> writes:
Ronald> Configure options for the cross-compiler are:
Ronald> --prefix=$HOME/tmp --target=i386-unknown-freebsd4.7 --with-newlib
It seems to me that a newlib build shouldn't enable Process support in
libgcj. So a different patch would be to change configure.in to use
the "Ecos" (a misnomer) process (non-)support instead.
What do you think about that? Do fork(), exec() and waitpid() really
work while signals do not? If so, that is very weird. Anyway,
assuming this makes sense, could you write the appropriate
configure.in patch?
There's other code around that assumes the existence of signals. For
instance, see the "*-signal.h" files in include. You'll also need to
deal with this somehow. Perhaps all newlib ports should use
-fcheck-references.
I think you'll find the newlib support isn't very up-to-date. It has
rotted a bit from disuse.
Ronald> 1. the file I patched should enever have been compiler
Ronald> (because I disabled threads on the command-line
FYI, natPosixProcess isn't thread-related.
Tom