…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>
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>
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>
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>
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>
Andrea Gelmini