libjava build failure on branch for sparc-sun-solaris2.7

Tom Tromey tromey@redhat.com
Wed May 23 19:11:00 GMT 2001


>>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:

Jeff> FAIL: Invoke_1 execution from source compiled test
Jeff> FAIL: Invoke_1 execution from bytecode->native test
Jeff> FAIL: Invoke_1 -O execution from source compiled test
Jeff> FAIL: Invoke_1 -O execution from bytecode->native test

These are probably problems with exception handling.

Jeff> FAIL: Thread_Alive execution from source compiled test
Jeff> FAIL: Thread_Alive execution from bytecode->native test
Jeff> FAIL: Thread_Alive -O execution from source compiled test
Jeff> FAIL: Thread_Alive -O execution from bytecode->native test

I don't know what these are.

Jeff> Tested on sparc-sun-solaris2.7 and i686-pc-linux-gnu.  Ok for
Jeff> branch?

Jeff> 2001-05-23  Jeff Sturm  <jsturm@one-point.com>

Jeff> 	* java/net/natPlainDatagramSocketImpl.cc: Undefine bind if defined.
Jeff> 	(_Jv_bind): New static function.
Jeff> 	(bind): Use _Jv_bind.
Jeff> 	* java/net/natPlainSocketImpl.cc: Undefine bind, connect if defined.
Jeff> 	(_Jv_bind, _Jv_connect): New static functions.
Jeff> 	(bind): Use _Jv_bind.
Jeff> 	(connect): Use _Jv_connect.

Yes, please check this in.  Thanks.

While this is ugly, I don't have a big problem with it even for the
trunk.  As long as it is documented, I don't see why it would be a
problem.  I think we'll see problems like this on various platforms
where a Java method happens to have the same name as some C macro.

I wonder if we want to put _Jv_bind and various net-related #includes
into a new header in java/net/ though.

Tom



More information about the Java-patches mailing list