Re: newlib and the use of fcntl by java

[Andrew Haley <aph at redhat dot com>]

Richard Earnshaw writes:
 > > >>>>> "Richard" == Richard Earnshaw <rearnsha@cambridge.arm.com> writes:
 > > 
 > > Richard> Hmm, it appears that java is making use of the fcntl function
 > > Richard> in newlib (or at least, it is trying to).  This is a problem,
 > > Richard> since most embedded targets don't provide this function.
 > > 
 > > Was this resolved to your satisfaction?
 > > 
 > > Tom
 > 
 > Well Jeff has changed Newlib so that fcntl now always returns -1 and sets 
 > errno to ENOSYS on configurations that don't really have fcntl support.  
 > That will fix the linkage problems.
 > 
 > I haven't had a chance yet to rerun all the libjava tests, and I don't 
 > know if they will trip the following anyway (or even if they are really 
 > relevant on an embedded target), but a quick audit of libjava shows the 
 > following cases where we use fcntl:
 > 
 > java/lang/natPosixProcess.cc:
 > 
 >       // Create pipes for I/O.  MSGP is for communicating exec()
 >       // status.
 >       if (pipe (inp) || pipe (outp) || pipe (errp) || pipe (msgp)
 >           || fcntl (msgp[1], F_SETFD, FD_CLOEXEC))
 >         throw new IOException (JvNewStringLatin1 (strerror (errno)));
 > 
 > Should we really throw the exception if the fcntl is not supported?  (I 
 > suspect it may not matter, since we can't start processes without a proper 
 > OS anyway).

Indeed.

 > Other cases in that file ignore the return value, so may be ok.
 > 
 > java/net/natPlainSocketImpl.cc
 > 
 >       int flags = ::fcntl (fnum, F_GETFL);
 >       ::fcntl (fnum, F_SETFL, flags | O_NONBLOCK);
 >       
 > This is setting properties of a socket, which also isn't really supported 
 > on a bare-metal system.

Or sockets, for that matter.

What we used to do was stub out the Posix-dependent stuff for an
embedded target.  See this in configure.host:

  xscale*-elf)
	with_libffi_default=no
	PROCESS=Ecos
	FILE=Posix
	CHECKREFSPEC=-fcheck-references
	EXCEPTIONSPEC=
	enable_java_net_default=no
	enable_getenv_properties_default=no
	enable_main_args_default=no
	;;

So we should *not* be loading natPosixProcess.cc on an embedded ARM
target.  Is the problem not simply that an entry in configure.host
hasn't been created for embedded ARM?

Andrew.