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

[Ronald Landheer-Cieslak]

On 17 Feb 2003, Tom Tromey wrote:
> >>>>> "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.
The problem is: I really don't know enough about gcc internals to start 
writing patches of any significance. That, and use of Newlib just isn't 
important enough for me to spend significant amounts of time on patching 
gcc to support Newlib correctly.

The patch I sent was the result of getting an experimental gcc 
cross-compiler to work, and seemed harmless enough to send in. It was not 
the result of any kind of in-depth research and, as I have a working 
cross-compiler at the moment, I probably won't get the time allocated to 
make a proper patch (the business I work for is just not that 
philantropic). Don't get me wrong: I would *love* to spend more time on 
this and get you a proper patch (with copyright assignment as needed) but 
at the moment, that is simply not an option.

If you wish, I can fill in a problem report describing the problem in a 
bit more detail, but I'm afraid that's about all I can do.

You should know that I am the first developer in my company that has any 
experience at all with free software - and thus I am the only advocate for 
free software here. (I am also the only one who knows his way around a 
*NIX box, always uses Cygwin and/or MinGW when working under Windoze, 
etc.)

Sorry, but I'm afraid I'm confined to trivial contributions for the time 
being.

rlc