| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: Ie8f2de8f11f8fec3a9f014bbcc46a506dfb3058d
|
| |
|
|
|
|
| |
Change-Id: I2b5e4abdceea25180c9caafabc49c22077016a05
|
|
|
|
| |
Change-Id: I022f7d450f66e1ff0fb4e4aedfebc16b83ad32b9
|
|
|
|
| |
Change-Id: I652ac46aec72a92667995353efa637f0a2310672
|
|
|
|
| |
Change-Id: I7e0eb7ba3be8ac2b70e6a56d84c1a890be0ba396
|
|
|
|
| |
Change-Id: I30ee99fe2a2e92c69ebfcef9af5ff1bb27ec114b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are basicically two classes of cases:
1) Where the code is for obscure historical reasons or what I see as
misguided "optimization" split into a more libraries than necessary,
and these then are loaded at run-time. Instead, just use direct
linking.
2) Where dynamic loading is part of the functionality offered to some
upper (scripting etc) layer, or where some system-specific non-LO
library is loaded dynamically, as it is not necessarily present on
end-user machines. Can't have such in the DISABLE_DYNLOADING case.
Change-Id: I9eceac5fb635245def2f4f3320821447bb7cd8c0
|
|
|
|
| |
Change-Id: Ib5da7703bf48713093bc6a3380facafd0013e039
|
|
|
|
| |
Change-Id: Idf092958e46a2ad9d56541c90c5a2beb44baff48
|
|
|
|
|
|
|
| |
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
|
|
|
|
|
|
| |
... new gb_LinkTarget_add_standard_system_libs
Change-Id: Ib2bc843098db3d8c6822b45a3d21724e67f57d69
|
|
|
|
| |
Change-Id: I53316e0b9369d806197bccb42cf22d3497af43e7
|
|
|
|
| |
Change-Id: I0733abb5c736ab393259fd6a005a89b887304f10
|
|
|
|
|
|
|
| |
...rather than a general RuntimeException, for consistency with existing service
ctor code.
Change-Id: Ia9ac14a1b5bcecb24394e7b9cade369f3f9303f0
|
|
|
|
|
|
|
|
|
|
|
| |
This is such a fatal error that there is probably no point in trying to handle
it, so allow to simplify client code by removing the requirement to check for a
null return value.
Simplified some client code accordingly (modules configmgr and ure, and the code
generated by cppumaker and javamaker).
Change-Id: I51c0b270ec73409374f7439a47ee061407a46e31
|
|
|
|
|
|
|
| |
Change-Id: I0e6992afbeffaf3b993e6630fb396d93012890e0
Reviewed-on: https://gerrit.libreoffice.org/632
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
|
|
|
|
| |
...more to follow (easy hack?)
Change-Id: Icb02626495701a3905c124c7368b98c3258e91b2
|
|
|
|
|
|
|
|
|
|
| |
removeRdbFiles suffered from a confusion that ImplementationInfo.uri denotes the
corresponding component (.so, .jar, etc.), but not the .rdb file. So removing
an .rdb file silently failed to remove the corresponding implementations, so re-
installing a similar enough .rdb (as typically happens during extension update)
would fail due to duplicate implementation names.
Change-Id: I25d4ff72656c99a3af509eef09e89c18cfd0aabe
|
|
|
|
| |
Change-Id: Ifddd6131c2e62057561d4b17eeda88568f6ccf7c
|
|
|
|
|
|
|
|
|
|
|
| |
Erasing from data_ member maps can destroy contained Implementations, which in
turn releases the UNO objects referenced from there, which in turn can cause
XComponents to dispose, which in turn can call arbitrary code, so must not be
done with rMutex locked. Witness the backtrace at
<https://bugs.freedesktop.org/attachment.cgi?id=65142> linked from fdo#52639
(where this fix appears otherwise unrelated to that issue's main topic).
Change-Id: If55a3841b761ec1d9a0ef61fe54784426c4ee442
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...in loadImplementation (instead of using the context the ServiceManager itself
was created with). Otherwise, the handcrafted context containing a fake
theJavaVirtualMachine singleton in install_vm_singleton
(javaunohelper/source/vm.cxx) would not be honored, so that if a Java process
bootstraps native (binary) UNO and from there tries to obtain that singleton, it
would erroneously try to instantiate another JVM instead of using the existing
one. This was a regression introduced with the new ServiceManager and could be
witnessed by test-javanative in ure/source/uretest/Makefile failing.
Change-Id: I58cfbc8cdaea7ee4ab80fac728ea3e85676d69e1
|
|
|
|
| |
Change-Id: Ied91b5b298f0cfad0d3408c3cbb87c7bd1b83247
|
|
|
|
| |
Change-Id: I459f7fd097a81ef5977974f52b0cc2c2f155a810
|
|
|
|
| |
Change-Id: I8fdfbebd9fd4bf19b57ec83689116c6fc77227e6
|
|
|
|
| |
Change-Id: I6a2ba2213d59ba73f7f170f40c7607f6ad23a0f4
|
|
|
|
|
|
|
|
|
|
|
| |
http://lists.freedesktop.org/archives/libreoffice/2012-April/029940.html
The RTL_USING #define (set by gbuild for anything that's not public
API) allows to use such classes simply by their name, without having
to use the namespace or do explicit using rtl::OUString (which half
of the sources do anyway).
Change-Id: I7edaf12cd278489cdc1d5ff782f0a86361c13c0a
|
|
|
|
|
|
| |
a literal within a OUString.
Change-Id: I01ca30c68228f81b3d313dfca5b975448f3c4fc7
|
|
|
|
| |
Change-Id: Ia6c0fbd33a4293ba863b4179f03f78ded413040a
|
|
|
|
| |
Change-Id: Id4210229b20a1d54b680ff1a2ccbcdd3684ecf5f
|
|
|
|
|
|
|
|
| |
missing { }
Untested as I don't have a working build environment yet.
Change-Id: I1988da8c07729eb99d3f53f71b8f950df29a7361
|
|
|
|
|
|
|
| |
...as some client code catches just the former and thus fails now. (This was a
regression introduced with the recent cppuhelper/source/defaultbootstrap.cxx.)
Change-Id: I8306797f8331d894ab4e7695478e3824e9f79197
|
| |
|
| |
|
|
|
|
| |
Change-Id: I5dfc43bdd4d8490a47c718dc49acba0ca5f7b526
|
|
|
|
| |
Change-Id: I6c145e984c885c7e06caa1c27bfb354ea49ad9ce
|
|
|
|
| |
Change-Id: Ice06e639213aeb6f7f23cbf4634947dd25613db1
|
|
|
|
|
|
|
|
|
|
| |
...the mangled names of the corresponding symbols change with MSVC if you change
a member from public to protected. This had been changed with
6e67c03dc0225fc66343546b14e902b9d238b1a3 "Enable -Wnon-virtual-dtor for GCC 4.6"
but should only be necessary for GCC, not for MSVC, so can simply be reverted
under _MSC_VER.
Change-Id: Id22aadaff3d7f30ed824f39fe22eab7ca39bd408
|
|
|
|
| |
Change-Id: I0ea47ee535ba0e903bae0de227acd311ca96aa03
|
|
|
|
| |
Change-Id: I0d2ebfc9aa78a9fed057b853d54797a88218c587
|
|
|
|
|
|
| |
This reverts commit b162aec6254ab535cc5eb990b249f46aa8e79153, which increased
code complexity for no benefit (the dubious scenario it was introduced for
concerned duplicate service rdbs rather than type rdbs, anyway).
|
|
|
|
| |
Change-Id: I8ecc2edde553edbd80ca04e2f3d541c31f516211
|
|
|
|
|
|
|
|
|
| |
...see comment in ServiceManager::createContentEnumeration for a rationale.
Splitting ImplementationInfo out of Implementation has become necessary to avoid
circular references.
Change-Id: I29aef81ce78b9ab71e18663f8c7e6ca913c6a650
|
|
|
|
| |
Change-Id: Ic70d66befc90450aeb276d53f6da7e81aef85478
|
| |
|
|
|
|
|
|
| |
Unfortunately this --enable-dbg-util only problem (caused by
_GLIBCXX_DEUBG) resurfaced, perhaps because of new std::string based
logging in sal; adapt all map files to export the unique symbol.
|
|
|
|
| |
Change-Id: Ifab63273b12963e748c9b937648b2079fcd0c796
|
|
|
|
|
|
| |
...that would otherwise lead to "Bad insert element" failure during live-insertion.
Change-Id: I74f883c9b613f03256abb7be7657f25b418f821d
|
|
|
|
| |
Change-Id: I50f0887ceb4517d7ef234f970ca2ba679d533382
|
|
|
|
|
|
|
|
| |
this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file
Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
|