| Age | Commit message (Collapse) | Author |
|---|
|
That flag is only supported by clang-cl, not by MSVC, and
c7c9f3f57a2feae5d3bc3c47104786883ed09e44 "use clang-cl's -Zc:dllexportInlines-
for clang-cl builds" apparently naively assumed that it would work to build LO
with clang-cl and that flag without actually trying it out, and
1040228c356d75c5228cde4d6103f9b446848e4b "My clang-cl build does not work with
-Zc:dllexportInlines-" effectively disabled it completely.
The way to avoid unresolved external symbols during linking of URE libraries
(see the 1040228c356d75c5228cde4d6103f9b446848e4b commit message) is apparently
to also build libraries that the URE libraries depend on with the flag, hence
the change from gb_Library_set_is_ure_library to
gb_Library_set_is_ure_library_or_dependency. For now, I only marked those
additional libraries (unoil and xmlreader) that actually caused issues when
linking the URE libraries.
Change-Id: I3a85c73246250981cd86b7ee41f87b41f393a4b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126012
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
|
|
This is clang-cl's equivalent of -fvisibility-inlines-hidden,
and it seems to be also sort of the equivalent of MSVC's
-Zc:inline. So it saves build time and disk space.
Clang docs say that this is binary compatible in only one
direction, so our public C++ code shouldn't be using this,
as external C++ code could try to use exported inlines
that are no longer there.
Change-Id: Ie6217808f8ee4a15344183abfc65038e1558d1b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122352
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.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: Ic02d217efef970a365a584f2558c41561e4c6e3d
|
|
Change-Id: I9d5b14c374ce62ac7b970faa30c38a5a76568ed4
|
|
Change-Id: I9cc9bfbddd3a90e00eee3e674994e5d6207f9034
|
|
This leaves only aborting stubs (for SONAME stability) for
typelib_static_array_type_init
typelib_typedescription_newArray
typelib_typedescription_newUnion
and completely removes corresponding
typelib_ArrayTypeDescription
typelib_UnionTypeDescription
structs and C++ inline
getCppuArrayType*
functions. None of this should ever have been called by client code anyway, so
while technically an API change it should not matter for practical purposes.
Change-Id: I23769d104d545533bf578762b79994e269d78c22
|
|
"UNO_ENV_SUBST:" should not be used.
Change-Id: If23b174de792cd69dc79e70dd8f5e8a31badb96d
|
|
If there is a SOVERSION then the versioned library is a real file and
the unversioned one just a symlink; better to have the real file be the
target.
- add gb_Library_UDK_MAJORVER variable for SOVERSION
- remove version parameter of gb_Library_set_soversion_script;
instead hardcode the SOVERSION since it must be included in the
file name in gb_Library_FILENAMES anyway
- store the unversioned symlink in the ILIBTARGET variable
- via new gb_Library_get_workdir_target_versionlink function
- removed gb_Helper_install call that resulted in both versioned
and unversioned libs in instdir
Change-Id: I2c6f1698f0e39fdb2c07964d43ed9485cbca0b30
|
|
|
|
Change-Id: Ib48a12e902f2311c295b2007f08f44dee28f431d
Reviewed-on: https://gerrit.libreoffice.org/3499
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I4ceee0ed3438a18e13c186ebd8d390604d26ec28
|
|
Change-Id: I22150c0247ec98bd0e764a439a15ceaa7f42b029
|
|
- 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
|
|
... new gb_LinkTarget_add_standard_system_libs
Change-Id: Ib2bc843098db3d8c6822b45a3d21724e67f57d69
|
|
Change-Id: I53316e0b9369d806197bccb42cf22d3497af43e7
|
|
|
|
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
|
|
|
|
|
|
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)
|
|
|
|
|
|
Because of unit tests is here custom target where are idl files
processed.
|
