…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
...which appears to be a better fit. Now, gb_JavaClassSet_JAVACDEBUG is
unconditionally defined as -g, but conditionally only used if
gb_target_symbols_enabled is true for the given target (where the target is
spelled "Jar/..." resp. "CustomTarget_jvmfwk/jreproperties" for the
--enable-sybmols=... mini-language in configure.ac). Also, the odd special case
to "force debug information for OOoRunner" has just been dropped.
Change-Id: Ief10efc689d65e2f50888d3e96cb40f43cbb1b2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165071
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Most of these don't use boost themselves, nor do they need
it transitively since the use of boost::optional was removed
Change-Id: Ic9dee1c4e160b313ec5b91677b02ffdea6c5779d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164440
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
that can be initialised at compile-time instead of runtime
Change-Id: I08d516fdc13a3a79f93c079f89ac44cbc7a1ed71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153620
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
This breaks existing paths which contain "\" or "$".
This reverts commit cfc2376f80.
Change-Id: Ia58df0a4f061f45140575e89231bd18d044a9bc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152604
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
This allows for relative paths to be configured as Java class path.
Change-Id: Ie3e6bc3836fb316457e5c9f11dfb77d2fcd49ad4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152271
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
the check is only done for windows & mac since the property can have
arbitrary values - in OpenJDK it is hardcoded for windows, but for other
platforms it can come from autoconf. For a more detailed explanation
see f05a42ef8c
Change-Id: I8555ef3b7153a9b744b45cf07deae3c3a1d48ae3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150119
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
when applying my upcoming patch to also consider O[U]StringBuffer
Change-Id: I8cf6a47ad357ddc73e2c430d966be72d5efd1485
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149767
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
where we can pass a string_view into OStringToOUString
Change-Id: If7803ba49aa15f6e9c7bd386d32fb84003155390
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148844
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_linux_s390 is
apparently dead and should thus be removed. However, that was the only bridge
implementation for 32-bit S390, which implies that support for the 32-bit S390
architecture as a whole is dead and should thus be removed.
Change-Id: I18b3b4fa11df4ce693107bad6bbea2fab1c19f26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
this is one of the secondary analyses this plugin performs
Change-Id: I1c496e234513362338600180e51f7e71e605a7cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143180
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
1. Configure gbuild
2. Add UNO Bridge for riscv64
Till now base function works well on riscv64. The bridgetest has passed.
Test on Debian, Gentoo and openEuler.
Credits:
- Heiher <r@hev.cc> and Stephan Bergmann <sbergman@redhat.com>
The riscv64 bridge implementation refers to mips64 and
AArch64 bridges.
- Bo Yu <tsu.yubo@gmail.com> configures gbuild for riscv64.
- WANG Xuerui <xen0n@gentoo.org> provides lots of guiding tips.
Change-Id: Ifad3b0de8b2c9e7328627ed03396bbd45a9c71e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137445
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
That check had been added with 32bc8ddbf3
"tdf#94716 allow Oracle's JDK to be used on OS X 10.10 and 10.11", back at a
time when there was substantial trouble with installations of Apple's own Java
and Oracle JREs. One consequence of that commit and its
JvmfwkUtil_isLoadableJVM check was that on macOS we only supported JDKs (with a
surrounding Contents directory containing an appropriate Info.plist files), not
plain JREs (cf. <https://wiki.documentfoundation.org/ReleaseNotes/5.1#macOS>
"Prior work arounds of having both an Apple JRE 6 and an Oracle JRE 8 are no
longer sufficient. Use of the JDK is now hard coded, see tdf#74877, tdf#94716
and core commit 32bc8ddbf335dd26019edcf12758643b4cff9913.")
However, Apple's own Java is long since deprecated (cf.
<https://support.apple.com/en-us/HT204036> "You can also download legacy Java SE
6 from Apple if you’re using an app that specifically requires this unsupported,
out-of-date version."), and presumably of no practical concern at least on
contemporary Aarch64-based macOS.
And there is e.g. SDKMAN! (<https://sdkman.io/>), which installs JDKs in a way
that they are not surrounded by Contents directories containing appropriate
Info.plist files, so JvmfwkUtil_isLoadableJVM returned false for them and you
couldn't add them on the LibreOffice Advanced Options tab.
So at least for Aarch64-based macOS, drop that presumably-legacy
JvmfwkUtil_isLoadableJVM check (but keep it for x86-64--based macOS at least for
now, just to be safe). (That implies that for Aarch64-based macOS, it should
now work again to also use plain JREs.)
Change-Id: I3bcbb3c14e3a9e9dde39fd6f4572b632e05df9e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141508
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...introduced in 655b6c2f46
"loplugin:stringviewparam". Unlike its O[U]String lastIndexOf(x, n)
counterpart (which looks for the last x whose end position, exclusive, is <= n),
string_view rfind(x, n) looks for the last x whose start position, inclusive, is
<= n. (So here would have left slash unchanged.) (And the seemingly simpler
jvm_dll.rfind('\\', slash - 1)
would fail when slash is zero, as in that case it would call rfind with a second
argument of npos, i.e., search for the last '\\' in the complete jvm_dll.)
Change-Id: I148a5db860d4b9e9d58a4a8847880a7a7020c5a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140486
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
Loongarch is a new RISC ISA , which includes a 32-bit version and a 64-bit version, Here are some documents about Loongarch：
https://github.com/loongson/LoongArch-Documentation.
The loongarch64 bridges implementation refers to mips64 bridges, and the code related to abi and asm has been modified
Change-Id: I1d9cd3aadf63046c8cdecc9a64842567bfa1cecc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137486
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which had been removed in 18bdf78e15 "Azul is
just another OpenJDK variant", when fixing the previously mis-classified Azul
JRE from "uses OtherInfo" to "uses SunInfo". But the IBM Semeru Runtime
(<https://developer.ibm.com/languages/java/semeru-runtimes/downloads/>) is
another arguably mis-classified case due to its java.vendor of "IBM Corporation"
(and where the
VENDOR_MAP_ENTRY<OtherInfo>("IBM Corporation"),
line in jvmfwk/plugins/sunmajor/pluginlib/vendorlist.cxx might be relevant for
some other JRE from IBM; at least, that entry is present ever since the
introduction of vendorlist.cxx in 738e9b77b9
"INTEGRATION: CWS jl8").
So just generally support the bin/server/jvm.dll path here for "uses OtherInfo",
even though it should actually only be necessary for "uses SunInfo".
(See the mail thread starting at
<https://listarchives.libreoffice.org/global/users/2022/msg00246.html>
"[libreoffice-users] LibreOffice 7.3.3.2 Windows 64 bit seems not detect
AdoptOpenJdk JRE Windows 64 bit runtime".)
Change-Id: I3a4d02309b7c833c3cd32dc2dda4f4cb7b216693
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133827
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
for which we have o3tl:: equivalents
Change-Id: I4670fd8b703ac47214be213f41e88d1c6ede7032
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
...like "11.0.14.1" reported now by
java-11-openjdk-headless-11.0.14.1.1-5.fc35.x86_64, and which caused
> warn:jfw:274674:274674:jvmfwk/plugins/sunmajor/pluginlib/sunjre.cxx💯 [Java framework] sunjavaplugin.so does not know the version: 11.0.14.1 as valid for a SUN/Oracle JRE.
(For simplicity, cover it with the same code block that already covers a
potential "_01" etc. part following the official(?) three dotted segments.)
Change-Id: Id98235d3be59653ab412f9b6c1ffbf3b0470bd6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131586
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
look for potentially trivial destructors that can then be elided
Change-Id: I435c251bd4291b5864c20d68f88676faac7c43fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131318
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...that had been added in 811de66d7f "First
attempt at getting access to the Java VM on Android", together with another
fprintf(stderr, "Got lo_get_javavm = %p", lo_get_javavm);
that had meanwhile been removed again in
5510127e89 "Android code refactorig and hacking"
Change-Id: I1a50563e2af1ea5a0ecbd2cc9d49d70c6e5bbbd3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130337
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Jenkins
...ever since 61c4f96d6a "Support AdoptOpenJDK":
At least the old AdoptOpenJDK 1.8.0_275 I had lying around on macOS reported it
as "AdoptOpenJDK", not "AdoptOpenJdk". But instead of fixing all occurences of
"AdoptOpenJdk", we can just as well get rid of that vendor listing completely
now after 3d27b2fa9c "tdf#124503: Support JRE
installations with unknown java.vendor property" and
3460c16d7f "Make getVersionInformation always
return a VersionInfo ...even for JREs not listed in javavendors.xml, making it
default to a VersionInfo with sMinVersion = "1.8.0". (For a rationale for not
updating the <updated> elements of the modified
jvmfwk/distributions/OpenOfficeorg/javavendors_*.xml see the commit message of
95c38f6d77 "Drop support for dead GNU Java".)
Change-Id: Iea34914201f604a0665a86dd07724628fa021c90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125402
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...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
<dbc9e4b50c>
"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>
