long obsolete; there's no IBM JDK for 32-bit ppc anymore. And it breaks
creating instdir/program/soffice with +x by cp (sed doesn't keep the
permission, obviously)
Change-Id: I9e8ffc6017056adb5142099a661761c2caaa87c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195487
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
The valgrind dhat plugin is no longer experimental as of
valgrind commit 441bfc5f5 in 2018, update the switch.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
Change-Id: Iba74eeed1cc5e2350d715454bf32192e0bc3692b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170072
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
The "which" utility is not guaranteed to be installed either, and if it
is, its behavior is not portable either. This means that when various
programs are installed, the `which` check will report a fatal error
because the which tool did not exist and the shell returned a nonzero
status when attempting to fork+exec. If it did exist, it might not be an
implementation of `which` that returns nonzero when commands do not
exist.
The general scripting suggestion is to use the "command -v" shell
builtin; this is required to exist in all POSIX 2008 compliant shells,
and is thus guaranteed to work everywhere.
For some in-depth discussions on the topic, see:
- https://mywiki.wooledge.org/BashFAQ/081
- https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250
Examples of open-source shells likely to be installed as /bin/sh on
Linux, which implement the 15-year-old standard: ash, bash, busybox,
dash, ksh, mksh and zsh.
This commit changes two programs installed to end-user systems.
Change-Id: I6013965bb914f5b0d593a876866b991e210ef5b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160662
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
With GNU gdb (Debian 13.2-1) 13.2, I noticed this trace on console when using --backtrace
Warning: 'set logging on', an alias for the command 'set logging enabled', is deprecated.
Use 'set logging enabled on'.
Change-Id: Ic03911ea94aff57dee8f594744147302ef01a1ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160143
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
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>
...after 4b9190fc29 "mac: don't put script files
into Contents/MacOS or framework-bin directory" moved it from Contents/MacOS/ to
Contents/Resources/
Change-Id: I90da34f73463baa516e81f6d06bd718f08e93af0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109627
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This moves the classes from juh.jar and ridl.jar to libreoffice.jar
The goal is to have one single jar (and Java module, will be added later)
which developers can include to work with LO.
juh.jar and ridl.jar are kept as basically empty jars with libreoffice.jar
on its classpath to keep backwards compatibility.
This is a continuation of ae855bf481
and a preparation to have Java 9 module support.
Change-Id: Ifbbfb97f60373d14256e62ae3122913bd17d5bbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91930
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
To be used also by Skia code to detect problems with Vulkan drivers.
The watchdog does not handle OpenCL because neither did the original
code, but also because OpenCLZone::hardDisable() called from it
would deadlock on SolarMutex for some reason.
Change-Id: I483d8cb0b11a4e1e65c564f4e4c29ab68843ff71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88008
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The previous way of doing
LO_SAVE_LC_ALL="$LC_ALL"
LC_ALL=C
export LC_ALL
# ... (call some tools,...)
LC_ALL="$LO_SAVE_LC_ALL"
resulted in the LC_ALL environment variable explicity being
set to an empty string in case it was not set at all previously.
For some reason, an LC_ALL explicitly set to an empty string
(other than an unset LC_ALL) makes the system ICU on various
Linux distributions assume an "US-ASCII" encoding, even if the
locale is otherwise configured to be a UTF-8 one.
Since the corresponding detection from ICU is used in the
KF5/Qt stack, that resulted in the Plasma-native file picker
assuming an ASCII-encoding, and thus having problems with
files containing non-ASCII characters.
To avoid this, don't export LC_ALL if unset or set to an
empty string.
A big thanks to frinring on IRC #kde-devel for the analysis
of why the Plasma-native file picker is affected by LC_ALL being
set to an empty string!
I could also reproduce that the following sample program run
with 'LC_ALL=' on KDE Neon Developer edition printed "US-ASCII"
when using the system ICU, while it printed "UTF-8" when using
a self-built ICU as of current master (commit
d6b88d49e3be7096baf3828776c2b482a8ed1780) instead, but did not
further investigate why:
#include <unicode/ucnv.h>
#include <iostream>
int main() {
std::cout << ucnv_getDefaultName();
}
Change-Id: Idee88f200b6edecdb2633ed6e6fa70b370ffcf0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88003
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Jenkins
jurt.jar and unoil.jar are kept as effectively empty jars, each with a
Class-Path: ridl.jar
in their meta-inf/manifest.mf, so that 3rd-party code loading them (with or
without also loading ridl.jar) will still have access to their content.
Conceptually, the UNOIDL entities in unoil.jar (corresponding to module offapi)
are not part of the URE, but are now made available by URE's ridl.jar. This
should probably not cause problems in practice.
At least for now, we seal exactly those packages in ridl.jar that were
originally sealed in jurt.jar. Ideally, all of ridl.jar could be sealed now,
but that would be mildly incompatible, as it would prevent 3rd-party code from
introducing additional UNOIDL entities in the relevant namespaces (even if that
is something we do not want 3rd-party code to do anyway).
However, some JunitTest_jurt_* define classes in those sealed packages. In the
past they got away with that by using gb_JunitTest_use_jar_classset,*,jurt.
Instead they now need to gb_JunitTest_use_jar_classset,*,ridl and drop the
gb_JunitTest_use_jar,*,ridl. But the former only makes available the classes
that are specified in ridljar/Jar_ridl.mk with gb_Jar_add_sourcefiles, not the
UNOIDL entities specified via gb_Jar_add_packagedirs. But the tests need the
udkapi UNOIDL entities, so introduce gb_JunitTest_add_classpath to let the tests
get them explicitly. (Curiously, JunitTest_jurt_uno and JnitTest_jurt_util use
gb_JunitTest_use_jar_classset,*,jurt but don't seem to acutally need it; lets
leave that for a follow-up clean up.)
As a follow-up clean up, relevant files could be moved from jurt/ to ridljar/.
Change-Id: I836f4e7bb47fb41f1306e3f223da90dba988eb9a
Co-authored-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84946
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Moved from TDF wiki to avoid duplication.
These three stop us getting poor performance from unusual allocators:
unset MALLOC_CHECK_ MALLOC_PERTURB_ G_SLICE
If we wedge, at least we don't do it while grabbing the mouse:
export SAL_DISABLE_FLOATGRAB=1
Turns off recovery dialog, which can be a pain:
export OOO_DISABLE_RECOVERY=1
Turns off GL watchdog. It normally kills the application, if it
seems to hang in a GL block:
export SAL_DISABLE_GL_WATCHDOG=1
Change-Id: I4ec30d363280b727cd305a6a81ccb85849697159
Reviewed-on: https://gerrit.libreoffice.org/73773
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
It avoids all those calls to _dl_runtime_resolve_xsave that
in KCachegrind's call graph lead to nowhere and make navigating harder.
Change-Id: Ie3843676298d92b8ed6d598ead16f4d410ba8b2b
Reviewed-on: https://gerrit.libreoffice.org/73382
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Since these don't use soffice they need to be tweaked to use RR variable.
A rr git master build from some weeks ago can record all tests, except
CppunitTest_dbaccess_firebird_test which fails.
smoketest is a bit tricky because it spawns soffice which checks RR
variable again and starts a nested rr, but fortunately there's a
flag to prevent it from aborting in this situation.
For UITests currently only the soffice.bin is recorded, not the python
test process.
The size of all the recording is about 35G per run in a --enable-dbgutil
build.
Change-Id: I2143618fa2181e36b6aaeded43637cb3481f5e47
Reviewed-on: https://gerrit.libreoffice.org/60032
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Michael Stahl <Michael.Stahl@cib.de>
javaPathHelper is a tool from OpenBSD ports, so there is no point
looking for it on other operating systems.
Change-Id: I763d717fdf7172b412d527fcd88347b2e54a8fe9
This reverts commit f52eb759f6. I assume this was
intented to be a fix for e6a9dc22a4 "tdf#105204
fix shellcheck warnings in desktop/scripts" (later addressed with
7ba0b28cc3 "Unbreak soffice.sh"). But I think
these quotations are actually useful parts of that original commit. I fail to
see how pathname expansion (aka globbing; nor field splitting, if that is what
was actually meant in "we want globbing here") should be a useful feature here.
Change-Id: I5c33c40cfe2a817f628442fed70a07f06dd275cc
This way should cover all un*x-like OSes (unopkg.sh excludes
e.g. OS X)
This effectively reverts commits 723e099972 and
9444ffc93a
Change-Id: I0b4425d1c9eff8e51e5d9a4dab35775084106a23
(cherry picked from commit faa2c06226146e3ab4b7fa8096cf213ea9d52a23)
with the exception of -h|--help.
It only makes sense to run unopkg with root priviledges if adding,
deleting etc. extensions system-wide for all users (i.e with --shared
switch ). In all other cases it only messes up access rights to
extensions, so prevent that. Furtheron, running LibO from the root
account (and installing root-user-local extensions) is not a
supported scenario.
Change-Id: I2817f62ae0bb400cefed240e792873f563fbe76e
Reviewed-on: https://gerrit.libreoffice.org/16250
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
The ../../../program/ links in the URE jar Class-Paths are a temporary kludge
(and juh.jar had lacked adaption for Mac OS X).
Change-Id: I2542d8a582866485dd61c05df3fc6b4b39a8403d
...or else they would end up non-executable in instdir, now that they are
directly copied there via desktop/Package_scripts_install.mk.
Change-Id: I8d2add1fd7f13ae9080d2f710b5fbb60d1e8ad1a
This makes sure shared extensions are readable by users when root's umask has been
set to a value such as 0027.
Change-Id: If495afae8eaf3a640c99ecb7598b79b59363c12c
Reviewed-on: https://gerrit.libreoffice.org/5521
Reviewed-by: Petr Mladek <pmladek@suse.cz>
Tested-by: Petr Mladek <pmladek@suse.cz>
* Support --version on non-UNX, too.
* Consistently show the first unknown option and the help blob in the presence
of any unknown options.
* There is no need to tunnel --help/--version past oosplash in the soffice
script, as oosplash is prepared to treat them adequately (esp. not pass them
over any pipe); this only added unnecessary variance to what spellings exactly
are supported and how mixtures of --help, --version, and unknown options are
handled.
Change-Id: I617f2e727e2f0eafd34a2de3b85d441c6783ec4f
Rene Engelhard