Add a second mode: When a classpath starts with '$', bootstrap variables are recognized.
The classpath must then be provided as URL, not native path.
Change-Id: Idcc229a2b4e9a512b0e712ea932a6e4293907db3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152899
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
a) When oosplash got SIGTERM it used SIGKILL on soffice.bin, (concealed
behind osl_terminateProcess) so soffice.bin has no chance to cleanup.
Try SIGTERM, followed by SIGKILL if that doesn't work, to give
soffice.bin a chance.
b) java intercepts SIGTERM so if JNI_CreateJavaVM was called then
our SIGTERM handler doesn't get called. Add -Xrs to jvm args to
avoid this.
Change-Id: I09f93d8093bc7c094482eda73b4eadc5a6cebb83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140152
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
look for call sequences that can use string_view and the new o3tl
functions in o3tl/string_view.hxx
Also add a few more wrappers to said #include file
Change-Id: I05d8752cc67a7b55b0b57e8eed803bd06bfcd9ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...otherwise if one such JRE had found its way into a user's configuration,
"Tools - Options... - LibreOffice - Advanced" would no longer show *any* JREs.
Regression introduced with 9143dd4ebe "Related
tdf#54443 List only matching JREs", which added WrongArch to the javaPluginError
enum.
Change-Id: I51fd47e585c6686be7a9282615c0978e4f6c460b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125396
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The commit message of e529461bcb "Enable JVM also
on macOS ARM64" had identified
<https://cdn.azul.com/zulu/bin/zulu17.0.63-ea-jdk17.0.0-ea.27-macosx_aarch64.zip>
"to work reliably now" while other (older Zulu) JVMs "have always crashed with
SIGBUS that smelled like our uses of pthread_jit_write_protect_np in
bridges/source/cpp_uno/shared/vtablefactory.cxx colided with corresponding calls
in the in-process JVM". Those observations would be in line with
<http://openjdk.java.net/jeps/391> "JEP 391: macOS/AArch64 Port" only
implemented for Java 17 now (see
<https://github.com/openjdk/jdk/commit/dbc9e4b50cdda35f5712deaf440c49f50b9edc96>
"8253795: Implementation of JEP 391: macOS/AArch64 Port").
So for macOS ARM64 assume that all OpenJDK variants (i.e., providing an empty
jvmfwk/distributions/OpenOfficeorg/javavendors_macosx_aarch64.xml) of at least
Java 17 (i.e., building on recent 3460c16d7f
"Make getVersionInformation always return a VersionInfo" and "change the
hardcoded '1.8.0' to '17' for just that one platform") work.
Change-Id: I11e8ba232cee066a25a49edebd0cc50e24e84124
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123989
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...even for JREs not listed in javavendors.xml, making it default to a
VersionInfo with sMinVersion = "1.8.0".
3d27b2fa9c "tdf#124503: Support JRE installations
with unknown java.vendor property", which had changed getVersionInformation to
return an optional<VersionInfo>, said in the commit message: "For simplicity,
assume that any versions of such JREs are supported. Our baseline is Java 6,
and there are unlikely any older versions of JREs from unknown vendors out
there." Our baseline is Java 8 by now, and there are still unlikely any older
JREs out there, but for macOS ARM64 we may want to restrict to at least Java 17
implementing <http://openjdk.java.net/jeps/391> "JEP 391: macOS/AArch64 Port",
and this commit is a prerequisite for such a change (where we would then e.g.
change the hardcoded "1.8.0" to "17" for just that one platform).
(OtherInfo::compareVersions in jvmfwk/plugins/sunmajor/pluginlib/otherjre.cxx
unconditionally returns 0, meaning "versions compare equal", so introducing a
default version of "1.8.0" should have no negative effect on any JREs that use
OtherInfo.)
Change-Id: I34dc5f2b755c2254a91d42c262786ceec70c746e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123958
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Exception looks like this:
java stack trace:
java.lang.UnsatisfiedLinkError: zulu11\bin\fontmanager.dll: Can't find depende
nt libraries
at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2648)
at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:830)
at java.base/java.lang.System.loadLibrary(System.java:1873)
at java.desktop/sun.font.FontManagerNativeLibrary$1.run(FontManagerNativeLibrary.java:57)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.desktop/sun.font.FontManagerNativeLibrary.<clinit>(FontManagerNativeLibrary.java:32)
at java.desktop/sun.font.SunFontManager$1.run(SunFontManager.java:279)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.desktop/sun.font.SunFontManager.<clinit>(SunFontManager.java:275)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:398)
at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:82)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74)
at java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.ja
va:189)
at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnviron
ment.java:223)
at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnviron
ment.java:251)
Change-Id: I7a16bb5813d4c089ddb4de34a250280cf6fee137
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119880
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The 'javasettings_${_OS}_${_ARCH}.xml' files are only
meant to be used when the application mode of the
Java framework is used, not in direct mode.
From ure/source/README:
> You can also use the
> UNO_JAVA_JFW_JREHOME deployment variable to specify the location of a JDK/JRE
> installation. For more information on this variable, see
> http://udk.openoffice.org/common/man/spec/javavendorextension.sxw.
From that http://udk.openoffice.org/common/man/spec/javavendorextension.sxw :
> The direct mode of the framework is used within the build environment.
> Java is needed there in order to register Java UNO components with the
> regcomp tool. Direct mode means that no settings are written or read.
> That is the parameters UNO_JAVA_JFW_USER_DATA and
> UNO_JAVA_JFW_SHARED_DATA are not used.
> [...]
> Another example for using the direct mode is the SDK. The SDK uses the
> libraries from the office installation. When an SDK is configured then
> one specifies what Java is to be used. This Java shall then be used for
> all task which require Java including registration of UNO components. In
> order to override the java settings of the office the script which
> prepares the SDK environment sets these environment variables:
> UNO_JAVA_JFW_JREHOME=<file_URL_to_selected_Java>
> UNO_JAVA_JFW_ENV_CLASSPATH=true
> UNO_JAVA_JFW_VENDOR_SETTINGS=<file_URL_to_javavendors.xml_from_OOo>
> By setting UNO_JAVA_JFW_JREHOME the framework is switched into direct mode
> and the office settings are disregarded.
Therefore, don't try to read the settings when using direct mode.
This makes the relevant code path for accessing the settings conditional
on 'jfw::JFW_MODE_APPLICATION' being used.
Otherwise, using direct mode e.g. by starting LibreOffice using
UNO_JAVA_JFW_JREHOME=file:///usr/lib/jvm/java-11-openjdk-amd64/ ./instdir/program/soffice --writer
then going to the "Advanced" options in "Tools" -> "Options", where
the Java settings reside would result in this SAL_WARN being triggered
warn:jfw:10207:10207:jvmfwk/source/framework.cxx:119: [Java framework] Trying to access settings files in direct mode.
and no JVM at all being shown in the list of available
Java installations.
Change-Id: I2b98d822aed2b160f970c50ca695a9f3beeacd34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104001
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
...now that 6ba7415086
"jfw::isAccessibilitySupportDesired is obsolete" demonstrated that there is no
more need for JFW_FEATURE_ACCESSBRIDGE, the sole feature that had been provided.
* The javasettings_*.xml format still supports the <feature> tag, but it is
ignored when reading and always written as "0".
* There is no trace that "the bootstrap parameter
JFW_PLUGIN_NO_NOT_CHECK_ACCESSIBILITY" whose mention gets removed from
jvmfwk/plugins/sunmajor/pluginlib/JREProperties.java had ever been supported.
(The only mention was 6873b3be47 "INTEGRATION:
CWS jre5issues (1.3.18); FILE MERGED: 2005/01/18 12:48:48 jl 1.3.18.1:
#i40879# in build environment the JRE is not tested for accessibility, because
of potential X server problems" introducing that comment.)
* The "Features" column is removed from the JRE table on the "LibreOffice -
Advance" options page.
Change-Id: I332d34b60548e7f2f852241ea8edfbee0ffcf510
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94329
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
noticed something that wasn't being picked up, wrote some tests,
and found an unhandled case in Plugin::getParentFunctionDecl
Change-Id: I52b4ea273be6614e197392dfc4d6053bbc1704de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90141
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...now that macOS builds are guaranteed to have std::optional since
358146bbbd "Bump macOS build baseline to
Xcode 11.3 and macOS 10.14.4".
The change is done mostly mechanically with
> for i in $(git grep -Fl optional); do
> sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \
> -e 's/\<o3tl::optional\>/std::optional/g' \
> -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i"
> done
> for i in $(git grep -Flw o3tl::nullopt); do
> sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i"
> done
(though that causes some of the resulting
#include <optional>
to appear at different places relative to other includes than if they had been
added manually), plus a few manual modifications:
* adapt bin/find-unneeded-includes
* adapt desktop/IwyuFilter_desktop.yaml
* remove include/o3tl/optional.hxx
* quote resulting "<"/">" as "<"/">" in officecfg/registry/cppheader.xsl
* and then solenv/clang-format/reformat-formatted-files
Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY is no longer set anywhere since
6dcb3d4ef4 "Related fdo#51252: No more prereg, no
more unopkg sync" in 2012. JFW_PLUGIN_FORCE_ACCESSIBILITY had been introduced
with 72b954df59 "Avoid using gconftool. Atk
provides a11y not Java on Unix" in 2013, as a means for users on Unix-like
systems to still force a JVM with a11y support, even though that should no
longer be necessary for LO a11y.
Both environment variables were documented as "unofficial", with the warning
that the "may be removed in the future." Theoretically, they could still be set
by some users, but the likelihood of their relevance today is considered low.
Change-Id: Ib718fb275b67a6de7fd7bc88ae428fd60168f4f4
Reviewed-on: https://gerrit.libreoffice.org/85140
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins
...and accompanying readme.txt. In the past, they got copied to "solver" and
were used during the build. bf0e30f9cd "jvmfwk:
remove Package_*solver" stopped copying them.
From jvmfwk3rc, the UNO_JAVA_JFW_ENV_JREHOME/CLASSPATH=true settings are found
in OfficeConnection::setUp (unotest/source/cpp/officeconnection.cxx) and
org.openoffice.test.OfficeConnection.setup
(unotest/source/java/org/openoffice/test/OfficeConnection.java), used during
tests. Setting UNO_JAVA_JFW_VENDOR_SETTINGS appears to not be necessary there
(presumably because those UNO_JAVA_JFW_ENV_* settings override its use anyway?).
The JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1 in sunjavapluginrc had been added
as the fix for <https://bz.apache.org/ooo/show_bug.cgi?id=40879> "java
framework: registration of Java components may fail", most of the relevant
commit messages mention "#i40879# in build environment the JRE is not tested for
accessibility, because of potential X server problems". There appears to be no
replacement that still sets it in post "solver" times, presumably because that
hack is just no longer relevant.
Change-Id: I3028b2f69c00eed3c5d2103345773b8daac409a0
Reviewed-on: https://gerrit.libreoffice.org/85136
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...with a boost::optional fallback for Xcode < 10 (as std::optional is only
available starting with Xcode 10 according to
<https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS
and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite
all code to use o3tl::optional instead of boost::optional.
One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per
fed7c3deb3 "Slience bogus
-Werror=maybe-uninitialized" should no longer be necessary (and whose check
happened to no longer trigger for GCC 10 trunk, even though that compiler would
still emit bogus -Wmaybe-uninitialized for uses of boost::optional under
--enable-optimized, which made me ponder whether this switch from
boost::optional to std::optional would be a useful thing to do; I keep that
configure.ac check for now, though, and will only remove it in a follow up
commit).
Another longer-term benefit is that the code is now already in good shape for an
eventual switch to std::optional (a switch we would have done anyway once we no
longer need to support Xcode < 10).
Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses
boost::property_tree::ptree::get_child_optional returning boost::optional, so
let it keep using boost::optional for now.
After a number of preceding commits have paved the way for this change, this
commit is completely mechanical, done with
> git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g'
(before committing include/o3tl/optional.hxx, and relying on some GNU features).
It excludes some files where mention of boost::optional et al should apparently
not be changed (and the sub-repo directory stubs). It turned out that all uses
of boost::none across the code base were in combination with boost::optional, so
had all to be rewritten as o3tl::nullopt.
Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b
Reviewed-on: https://gerrit.libreoffice.org/84128
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Noel Grandin