Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.