Age | Commit message (Collapse) | Author |
|
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: Ifcfa48fc87f905a91470a5b0fd597b02f220784c
Reviewed-on: https://gerrit.libreoffice.org/671
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: I0733abb5c736ab393259fd6a005a89b887304f10
|
|
Change-Id: I52c176776a58a633d0125449fdaa550c813e7da0
|
|
Change-Id: I317058e3b25cebb7c1d89361636261c5f16a84d4
|
|
Change-Id: I9ccf664e8f75a68b1b87c2b29ae617a90d0741a7
|
|
Those classes don't exist. So remove friend class operators too.
Change-Id: I8e3b32db933dea7cbab86015f0c926df967511f6
|
|
Change-Id: I8fdfbebd9fd4bf19b57ec83689116c6fc77227e6
|
|
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
|
|
Change-Id: I7c62d086cb593744785abecae7a107686a4d65ce
|
|
Those are unused too.
Change-Id: I09c9dbcdbc68131c7c54bf0762a23f1280e6e22a
|
|
|
|
Change-Id: I6c145e984c885c7e06caa1c27bfb354ea49ad9ce
|
|
Change-Id: Ice06e639213aeb6f7f23cbf4634947dd25613db1
|
|
Change-Id: I0d345b2cf60f49e0e6b72724251c1f6d30529dce
|
|
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: Ifd7a248b49a00df2e01f537074d0a94e9de09b10
|
|
Change-Id: I6a178f7ff9c8306e15bcfa847ad1e5e4f8476504
|
|
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
|
|
|
|
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)
|
|
|
|
The assumption in the comment is clearly wrong, as osl::Thread::create
returns a boolean result to indicate failure.
Slight modification of a patch by Michael Stahl <mstahl@redhat.com>.
|
|
|
|
|
|
|
|
|
|
...also improved the code somewhat.
|
|
|
|
|
|
|
|
|
|
* New build prerequisite doxygen (controllable via --with-doxygen).
* Adapted various headers to slightly different doxygen documentation
syntax, but much clean up still remains to be done (i.e., warnings
emitted by doxygen fixed).
|
|
|
|
This is a cherry-pick of Matúš's e2f30c078fcf26d481c2e90398b450f6c475a483
from the feature/gbuild branch, with the following modifications by
Stephan Bergmann <sbergman@redhat.com>:
* Adapt salhelper/Makefile to what all those Makefiles currently need to
look like.
* Do not remove salhelper/source/gcc3.map, instead add directly into it
what otherwise solenv/bin/addsym.awk would add to it on Linux.
* In salhelper/Library_salhelper.mk, add code that on Linux takes care of
the soname and symbol versioning required for backwards compatibility.
Solaris would need those features too, and its backwards compatibility
is thus currently broken. Also add a bad hack to create the soname
symlink (xxx.3 -> xxx) in the solver needed on non-Windows platforms (it
is a bad hack for now in that it e.g. is not removed by "make clean").
* In solenv/gbuild/platform/macosx.mk, add an even worse hack to set the
correct install name for libuno_salhelpergcc3.dylib.3, with a trailing
".3".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|