This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] to java::lang::ConcreteProcess::destroy


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]