> 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? 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. --tml _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
