Age | Commit message (Collapse) | Author |
|
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
|
|
And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Avoid the use of unnecessary local variables to temporarily keep
return values from a function called by the inline assembly. Instead
use the GPR and FPR arrays also to temporarily keep such return
values, like the Linux aarch64 code does.
This fixes https://github.com/CollaboraOnline/online/issues/5204
Change-Id: I11aac56e9c8cc8aff1a3653ced45bdf4844cbcca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139604
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I295d7877100b49a867a0f67e2edcc923d943401b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138664
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I846746a351c619a4de7abce7a6443f510dc41690
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138661
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I9374a580d3dce7c7851881ff8193946d46ed2bec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138384
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1b73d68b007ba0dfa54f99ff8f8fea55e94a1ed2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137651
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: I5b7a0fa060c1e0ae4aa194e0c1862f303dd8a2d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138062
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
as that what it actually is and the compiler defines are already
-DMIPS/-DMIPS64 anyway (as are the PLATFORMID and the bridges'
name mips/mips64)
Change-Id: I274e7a3b0e140375a8e697c1790cbdb972251d29
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137489
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: René Engelhard <rene@debian.org>
|
|
Change-Id: I7bd02dba44a8bc62da660bcb7500960ef14172a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136939
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Change-Id: Ie8c04a8c414f32cc0e68fbab1d24a9707f179011
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136201
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6c52316e46117aacb22a2adcb75841aed834041f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134705
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
found by inspecting call sites of OUString::getToken
Change-Id: I4269c7476c7aa46fac39528227e350568f0eb34a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132644
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4bd3efe67217a4c4418cf308cc8e7a55cf4a604a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133390
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I842668655dec102e1595dcbac6413fe2b49d8515
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133268
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I07b215067b1cefc87919680fad3299d702ff6d1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132100
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...that had been introduced with 7e8e85adbee73346403c364326544487677cd5c6 "Add
codeSnippet debugging output when dbglevel>1" and reinforced with
6f121860d0537060084278da11842732a748d6b7 "tdf#130924 replace debugging printf
calls with SAL_INFO/SAL_WARN"
Change-Id: I9529bfdedd3d1a3dd623fdb28e01d6bd96c92d97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131169
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iaef5eec6508d031ab711a71c0d8ecebb18112ef6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130764
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
...when building on Linux with Clang -stdlib=libc++,
> In file included from bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:41:
> bridges/source/cpp_uno/gcc3_linux_x86-64/share.hxx:156:51: error: Replace legacy dynamic 'throw ()' exception specification with 'noexcept' [loplugin:noexcept]
> extern "C" __cxa_eh_globals * __cxa_get_globals() throw();
> ^~~~~~~
(The situation with respect to these exception specifications is a bit unclear,
recent <https://github.com/itanium-cxx-abi/cxx-abi/blob/main/abi-eh.html>
doesn't mention any exception specifications for those effectively extern "C"
functions, and recent
<https://github.com/llvm/llvm-project/blob/main/libcxxabi/src/cxa_exception.h>
doesn't have an exception specification for __cxa_get_globals and recent
<https://github.com/llvm/llvm-project/blob/main/libcxxabi/include/cxxabi.h>
doesn't have one for __cxa_current_exception_type though it has `throw()` for
__cxa_allocate_exception. On the other hand, recent
<https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/libsupc%2B%2B/cxxabi.h>
and
<https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/libsupc%2B%2B/cxxabi_init_exception.h>
have _GLIBCXX_NOTHROW exception specifications for all three functions, which
expands to `noexcept` for C++11 and beyond.)
Change-Id: I1582c9d3b42977af011d4dc49674fdf12d5ea5ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130926
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
... and use the same fake exception rethrowing code then the
mobile platforms.
Change-Id: Ic90de1cfd1e0092d6064d041a613d60d9f5f76b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128596
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
It missed some occurrences of 0 when only looking into uninstantiated template
code, as Clang doesn't model them with an ImplicitCastExpr, even if the target
is known to be a (dependent) pointer type.
Looking into all template instantiations of course carries the risk that a given
use of 0 is meant to be interpreted as a pointer in some and as an integer in
other instantiations. But the only case where that happened in the current code
base is RegistryValueList::getElement (include/registry/registry.hxx), where {}
is arguably a better choice anyway. (And which would presumably also hold for
any future such cases.)
Change-Id: I708bcfc8bedc0a49c9282d7814eb325afa29905c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128462
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
copy and paste recommendation from:
https://sourceware.org/annobin/annobin.html/Test-cf-protection.html
and adapt like:
https://github.com/openssl/openssl/commit/51994e505dbb1cd0dd76869ec962e2948b77b585
where https://bugs.ruby-lang.org/attachments/8962 is similar
Intel docs have "The ENDBR32 and ENDBR64 (collectively ENDBRANCH) are
two new instructions that are used to mark valid indirect CALL/JMP
target locations in the program."
Change-Id: Ie867c263a888763db4478720ba189c9ec6cc974d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126859
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
How did that even pass in Jenkins on Android Arm?
Regression from commit c859b4aa48956cbf5ff41280b0008456e8f5189c
("gbuild: introduce gb_%_linktarget_target").
Change-Id: Id06cc151e92e221da856814d69eb8cced167b427
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127829
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Just some refactoring.
Change-Id: I47adb93f8a413d289f6abb2a48ed3f049f582a46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127799
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I836412674448acb2a047d3d8b4711fa8d0b67257
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127410
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The lock_guard moved from RTTI::GetRTTI to x86_64::getRtti to avoid recursive lock.
Change-Id: I0e71581dd57a4fb2655d4b9040fb9d943f73ab9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127095
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
This introduces two concepts: a plugin and its loader (library)
LO currrently has dependency cycles for some libraries. There is
scui, which depends on sc, while sc dlopen's scui. There are the
various vclplug_*, i18npool plugins, filters/gie, acc, etc.
Usually these plugins link to their loader library, because they
use its symbols. But as a result there is no sensible way to
express the runtime dependency of loaders on the plugins.
In GNU libtool plugins are called modules and they are implemented
in an IMHO more sensible way by allowing missing symbols at link
time. This way you can have a dependency from the loader library
to its plugins, as the plugins don't depend on the loader, but you
lose the link time detection of missing symbols.
While this is in theory possible in LO too, LO currently has
plugins, like acc (accessibility), loaded by tk (toolkit), which
depends on svt (svtools), which itself depends on tk, so dropping
the tk dependency for acc on its own doesn't help :-(
And while the dependency of the plugins on their loader is fine
for the shared / DYNLOADING build, for the "static" builds you
must (somehow) link the plugins into the executables.
I also codeified a few rules into the build system along with it:
* just plugins are allowed to depend / link other plugins
* plugins aren't allowed to be linked into the merge lib
* plugin loaders are "limited" to libraries
At the high level, this is implemented via new gbuild calls:
* gb_Library_set_plugin_for,lib,loader: declare a library to be a
plugin of a loader library and add a dependeny from the plugin
library to the loader library
* gb_Library_set_plugin_for_nodep,lib,loader: ^^^^ without adding
the library dependeny
* gb_Helper_register_plugins_for_install: "plugin" replacement for
gb_Helper_register_libraries_for_install to implement some
additional checks in the build system
In the end this patch just adds a bit syntactic sugar and nothing
changes for any build.
Change-Id: I7b01d9c384cbc5838bd2cc93aff18e4868939d6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126163
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This partially reverts 1a5b12aa5da2c718848d3cc5d9bce7bfcdeacf54 "optimise
find/insert pattern", which caused
> ~/llvm/inst/bin/../include/c++/v1/unordered_map:1134: _LIBCPP_ASSERT '__get_const_db()->__find_c_from_i(&__p) == this' failed. unordered_map::insert(const_iterator, const value_type&) called with an iterator not referring to this unordered_map
during CustomTarget_testtools/uno_test in an experimental build with
-D_LIBCPP_DEBUG=1 on macOS.
Change-Id: Id40e5eab7c3fb1f8e1bb2599c7fb84649e870ba2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124319
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
<https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Pass-Arguments-to-Functions-Correctly>
only mentions function arguments, not return values in "The caller of a function
is responsible for signing or zero-extending any argument with fewer than
32 bits. The standard ABI expects the callee to sign or zero-extend those
arguments." But this appears to also be relevant for return values, where the
callee apparently has to provide properly extended values: Without this change,
in an --enable-optimized build, e.g. selecting "Tools - Macros - Organize Macros
- BeanShell... - LibreOffice Macros - Capitalize - capitalize.bsh" would not
enable the "Run" button, as in SvxScriptOrgDialog::CheckButtons
(cui/source/dialogs/scriptdlg.cxx) node->getType() (which returns a sal_Int16
value, and which calls DefaultBrowseNode::getType,
scripting/source/provider/BrowseNodeFactoryImpl.cxx, which in turn calls
m_xWrappedBrowseNode->getType() on a proxied Java object via the UNO bridge)
would return a value in r0 with bits > 16 left with random values, while the
calling code assumes them to be zero (and exploits that violated assumption with
--enable-optimized).
Change-Id: Ic99dd9e62b49b44e13cdde6158bef7e2296547f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123550
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71fabde4dba990bfceb61bbe8e06b8ea
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ifede38f3b19d1e5226e18dba1aa21d478a430d9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120763
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: I8360aa96097a13b6bad1283edddc7c2fd1ed510d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120832
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
which went a little wrong in
commit dd91d3389c26645459d3b80649941d65efa4f63f
Date: Sat Jan 2 14:36:44 2021 +0100
Fix some warnings for Raspberry pi 4 (part3)
Change-Id: Ief7e1146b7480a1c16ec0810f991296710214332
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120830
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
possible regression from...
commit 6e3424ca1131fe371f63e456267de476b5eb0eae
Date: Sat Jan 2 11:03:12 2021 +0100
Fix some warnings for Raspberry pi 4 (part2)
which changed that
Change-Id: I9a19d7d6bc1e4115ffffbe32d8d62be5d275d500
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120747
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: René Engelhard <rene@debian.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I9f8fe250813f4f376dc46c6f3d7e25e90fdbb50e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120566
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
as in commit 9376f65a26240441bf9dd6ae1f69886dc9fa60fa
Change-Id: I3ad9afd4d113582a214a4a4bc7eea55e38cd6ff9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119927
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...similar to ca344be7aabf88dddde38841e6af6292ece6829b "tdf#143450: Fix special
fp+integer struct return case for gcc_*_x86-64"
Change-Id: Ia8110d632a1c5f328822c434efc5b09bd53ec9e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119883
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and
cid#1489552 Uninitialized scalar variable
Change-Id: I056cfd95d34f2163e68b83cce21bce70ccf5fc8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119701
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...to convince myself that it is only about the initial %rsp/%rbp fiddling, and
is not affected by the ca344be7aabf88dddde38841e6af6292ece6829b "tdf#143450: Fix
special fp+integer struct return case for gcc_*_x86-64" changes to later parts
of privateSnippetExecutor
Change-Id: I7bfad4cb5e1c2208e29c73a70874b6e9eff29eb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119610
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
For one, the loop in x86_64::fill_struct was backwards.
And for another, privateSnippedExecutor does not need special handling of FLOAT
and DOUBLE return values (they can simply be moved to %xmm0, as covered by the
general case), but rather for those small structs where floating-point member(s)
in a first eightbyte (targeting %xmm0) are followed by integer member(s) in a
second eightbyte (targeting %rax). Extended testtools to cover two such cases.
Change-Id: I8e775a1d1ce2312610f265bcc8e40b09bdac56df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119576
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
same as 5411aafbfd8656f043bcf30588bc41b061f1b60b "Clean up
bridges/source/cpp_uno/gcc3_linux_x86-64/abi.cxx"
Change-Id: I25ba66f2d666ef108265d308b7cc9badba60ae2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119579
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...without any intended functional changes, in preparation for actual fixes for
tdf#143450 "Data corruption when returning small structs containing a double
from C++ via IPC".
Much of the code (apparently originally copied from some other project,
according to the comments) was too generic for our specific needs here.
Change-Id: Iddcb58fa0999d10dcf716dd2af7dab1620839bce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119570
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This reverts commit 739aaf02db3353fac8490272cab0c9486570f76d. At least in
bridges/source/cpp_uno/gcc3_macosx_x86-64/except.cxx, getRTTI can call itself
recursively, causing a deadlock on RTTI::m_mutex. In
bridges/source/cpp_uno/gcc3_linux_x86-64/rtti.cxx that has been addressed with
RTTI::getRTTI_NoLock, but other implementations have not been modified. Avoid
regressions, esp. on more esoteric platforms, by reverting the change.
Conflicts:
bridges/source/cpp_uno/gcc3_linux_x86-64/rtti.cxx
Change-Id: I08b57b0561923bdbe191c8e93f8f400e0e4df337
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119442
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If56de2708254348b6b759ecdd2b1fb259562af69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119169
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I changed all the bridges to keep them in sync, but only
tested on the LibreOffice CI machines.
Change-Id: Id8fef017cc6c99c60d64b8f849220d5336abc5d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119140
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie973ef2923c1c725ee740000ebd1eacf671a5bfb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119139
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I was wondering why removing instdir stuff forced a rebuild of
the cross toolset. Turned out some cross-toolset bits were wrongly
depending on host build stuff. It even had FIXME...
As a consequence, gb_CPPU_ENV was replaced by config_host.mk flags
to provide an CPPU_ENV_FOR_BUILD and also uses the correct
OS_FOR_BUILD.
Change-Id: I50e8e8dca50ab1ad3164948a585a792a52e4a39a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116359
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: Ife669f959358992b547b408ab5d1f6bf1c1d14bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115744
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7eede75da6b81777661e0e5b76c8877e122f941b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115224
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|