newlib and the use of fcntl by java

Wed Sep 25 04:09:00 GMT 2002

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.