On 04/11/2012 02:04 PM, Tor Lillqvist wrote:
The one problem is that UNO "named pipe" (i.e., --accept=pipe,name=foo;urp)
communication, even from within a pure Java environment, needs some native
code (jpipe JNI library) which obviously needs to be available in the format
of the JVM process's architecture.
OK. So would it be feasible to build this jpipe JNI library also as
64-bit code, even if LO as such is built as 32-bit code? (We already
have some mechanisms for stuff like this in place, to build the
Explorer extension code also as 64-bit.) (Whether that actually works
is another question, though, there has been bug reports about the
Explorer extension recently...)
The source for this jpipe library (or actually, for jpipx.dll, which
is wrapped by a thin jpipe.dll on Windows) is
jurt/source/pipe/com_sun_star_lib_connections_pipe_PipeConnection.c, I
assume?
Should be doable. Question is if it is worth it. There might be
additional native code involved that I forgot about. I would first
check whether using TCP sockets instead of "named pipes" for UNO
communication solves the OP's problem. An alternative would be to
invest work in a 64 bit Windows LO. (Another alternative might be for
the OP to use 32 bit Java on Windows?) On the con side, every addition
makes the fat code base even fatter.
I see that it does #include "osl/security.h", and that jpipx.dll
imports from sal3.dll a handful of osl_ and rtl_ functions. So those
would have to be built as 64-bit code, too. Still, not rocket science.
(I would even say that it would be best to just copy-paste those
functions into the com_sun_star_lib_connections_pipe_PipeConnection.c,
and not have any separate wrapper dll at all, just a jpipe.dll that
doesn't import sal3.dll.
I would prefer keeping the wrapper library here instead of duplicating code.
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
