| Age | Commit message (Collapse) | Author |
|---|
|
That check had been added with 32bc8ddbf335dd26019edcf12758643b4cff9913
"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>
|
|
...which no longer worked anyway at least since
aafc10c9edb61e13ac557c7e43c8d4a31dce4f37 "Bump Java baseline to Java 8":
According to <https://en.wikipedia.org/wiki/GNU_Compiler_for_Java>, the last
version of GCC providing Java was GCC 6.5. But trying to add a build of that
("Tools - Options... - LibreOffice - Advanced - Java Options - Add...") would
already have failed before this commit due to a java.lang.ClassFormatError
("JREProperties (unrecognized class file version)") when executing the
JREProperties code compiled with --release 8. (Whereas now it fails because it
cannot even determine a JRE installation there according to the SunInfo rather
than GnuInfo rules used for the now-unknown vendor.)
The <updated> elements of the modified
jvmfwk/distributions/OpenOfficeorg/javavendors_*.xml have not been updated in
line with the rules documented at the end of jvmfwk/README.md: As mentioned
above, a GNU Java JRE cannot have been selected prior to this commit anyway, so
even though this is nominally an incompatible change of the xml files,
actually updating <updated> would only have negative ("just annoying if an
already selected JRE is still supported") but no positive consequences.
Change-Id: Ica245677dae977360bdb3c6544897eb060c3f844
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123906
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Uwinapi is discontinued.
Change-Id: I063b4d0d8fab2d60de168e960a63b8181158ac01
Reviewed-on: https://gerrit.libreoffice.org/23198
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
|
Change-Id: Ide9b4beebb407e4ceee30f1d99f29d028c848d8c
Reviewed-on: https://gerrit.libreoffice.org/19131
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: I954f789d5850e8016f5900812f9aa99be2416ce4
|
|
...which was effectively unused; there only ever was a single sunjavaplugin that
is now folded directly into jvmfwk. Leaves room for further clean up.
Change-Id: I14dd2a3a09bd1ce9a8c3f5c156628ec11d954a0b
|
|
Change-Id: I8e9f70eb5d929c98b4379416c2259a74e31d587f
Reviewed-on: https://gerrit.libreoffice.org/3503
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I400fad08c0ae7b6b34bad63693f54856867e4dac
Reviewed-on: https://gerrit.libreoffice.org/3502
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
|
|
Change-Id: I2b2099d8fc00062f67c42e73c4b8a17a689db89d
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I54d8923ad315e8041fd3904da3a29f1a7a8c8b16
|
|
- do not use gb_UnpackedTarball_copy_header_files for boost
- adapt the optimization in concat-deps.c for new path
- use boost_headers in all LinkTargets that require it
- add explicit include paths to mysqlc, mysqlcppconn, libvisio, liborcus
Change-Id: I0c43e73ed43cc9d2e6bce8faf55e992d655a0bb9
|
|
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
|
|
add a new gb_LinkTarget_use_system_win32_libs to abstract different
linker options on MSVC and GCC.
Change-Id: Ic9bf2545f59bf7871e6fc06b290c486ddfbec03d
|
|
... new gb_LinkTarget_add_standard_system_libs
Change-Id: Ib2bc843098db3d8c6822b45a3d21724e67f57d69
|
|
Change-Id: I53316e0b9369d806197bccb42cf22d3497af43e7
|
|
|
|
Naming convention for gbuild methods:
- "add" is used for stuff that is logically a part of the target
(i.e. not registered at the Module, but defined in the target's makefile)
- "use" is used for stuff that is logically a different target
(i.e. it is registered at the Module, has it's own makefile, may be
in a different module than the target)
|
|
|
|
|
|
|
|
|
|
|
