With just the Oracle JRE installed, it is not possible to load the
"jvm.dll" directly, because the required MSVC runtime DLL is not
found (unless some other software happens to install it system-wide),
as described in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184978
There was a hack "do_msvcr71_magic" to manually load the runtime that
is bundled with Oracle JRE 6 and this generalizes that to work with the
MSVCR100.DLL that is bundled with Oracle JRE 7 as well.
An additional adaption of the virtual addresses in the file is done,
and it's a mystery whether it even worked before without that.
This issue was not user-visible before because LO releases 3.5 - 4.2
bundle the MSVCR100.DLL themselves.
Change-Id: If61565df80ff8a68472a76000ab5b10d6c78e11c
...not only on Mac OS X. Was able to reproduce this on Fedora 20 where current
JRE was /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.x86_64 but for whatever reason
there was also a left-behind /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.0.x86_64 tree
(containing just a handful of sub-dirs, but no real content) that was still
recorded in my ~/.config/libreoffice/4/user/config/javasettings_Linux_X86_64.xml
Change-Id: Ie477c5a506a430f6c29525f6c558dbc18bbf1c48
...for one, it doesn't appear necessary there ("needed for awt"), and for
another setting it according to Oracle's JRE 7 would prevent a subsequent
visit to the Advanced preferences pane from listing Apple's JRE 6, as launching
that java and reading its system properties would be fooled by the JAVA_HOME and
report the Oracle system properties instead.
Change-Id: I02d82de6113b44b3cae3fb55cd83177fe852d769
...to improve diagnosing misuses of boolean expressions in client code (cf.
compilerplugins/clang/implicitboolconversion.cxx). This change should be
transparent to client code.
Missing overloads of insert() for bool have been added to OStringBuffer and
OUStringBuffer (which required dropping one !VALID_CONVERSION check that would
now pick that overload, but would be flagged by
compilerplugins/clang/pointertobool.cxx).
Change-Id: I2d64cd923b8f47bfaa31e753def6515c29a3f8c9
The uninitialized Module variable causes the smoketest to fail when
built with MSVC 2012 (assinging to it raises some weird exception).
Change-Id: I77b3b591a94f4dfbb373938e3787f75e6a8e09c5
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
Sorry for the large unstructured commit. But hey, the Android code is
experimental so far.
Extract the native lo-bootstrap code into a fairly normal library
built in sal. (Previously it was the JNI part of the "Bootstrap" app.)
Just linkink normally to liblo-bootstrap from C++ code that uses it
works fine, no need to do a dlsym lookup.
Bootstrap is still a subclass of NativeActivity and can thus still be
used as an "app" (to start unit tests, or whatever), but can also be
used from some other app's Java code to just get access to the
lo-bootstrap native methods.
Introduce a new top-level "module", android, for Bootstrap and the
experiments with DocumentLoader.
Note that the experimental DocumentLoader app still crashes. It can't
create the com.sun.star.frame.Desktop instance.
I spent lots of time debugging in the painfully inadequate
ndk-gdb. (Even the newer gdb build from the "mingw-and-ndk" project is
quite crappy in many ways.) I should really experiment with
corresponding code on a normal platform first before even trying on
Android. Basically, I think that if I just can get the concept of Java
code that instantiates and uses LO components *in-process* working on
a normal desktop platform, it should work on Android, too.
That file compiles fine without them. These headers are in tools,
which hasn't been built and delivered yet when sunjvmfwk is built. We
can't add tools to the dependencies of jvmfwk as that would introduce
circularity.
As such, I see no reason why prewin.h and postwin.h are in tools. I
think they should be in solenv, like premac.h and postmac.h. It would
perhaps be an Easy Hack to move them, and drop the "tools/" from all
lines including them?
