summaryrefslogtreecommitdiff
path: root/external/librevenge
AgeCommit message (Collapse)Author
2015-09-17blind attempt to fix lcovDavid Tardon
Change-Id: If8d6c8da1be1e540d641f20ac90e7877feae27be
2015-09-01core: fix build with system boost 1.59David Ostrovsky
9a6cdce37e601b1406c71fef16ad9b315045c9da was trying to fix the problem with exposing deprecated vars and functions in system's error_code.hpp include file by patching bundled boost version. This approach would only make sense, when upstream version is going to be fixed ASAP. Apply another approach, and follow the same pattern as applied in external libraries, by defining -DBOOST_ERROR_CODE_HEADER_ONLY \ -DBOOST_SYSTEM_NO_DEPRECATED instead of patching bundled boost version. This way, the code would work with unpatched system boost 1.59 final as well. Change-Id: I8684ca458ea4a5b7d7c3c3acfe7c14a6d19bc665 Reviewed-on: https://gerrit.libreoffice.org/18201 Reviewed-by: David Ostrovsky <david@ostrovsky.org> Tested-by: David Ostrovsky <david@ostrovsky.org>
2015-08-11gbuild/config stop using VERBOSE, use only verbose=tNorbert Thiebaud
configure.ac was setting VERBOSE=YES/NO when really we use verbose=t or verbose= Change-Id: I47aee8d177cb2d788a62ecdbbb9cc3695c2bb299 Reviewed-on: https://gerrit.libreoffice.org/17634 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
2015-08-07librevenge bundled soname patchAndras Timar
Change-Id: I8c55eb6eeca40faf8201af037f31a57ce9b64ac0 Reviewed-on: https://gerrit.libreoffice.org/17572 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2015-06-05use $(DISABLE_DYNLOADING) consistentlyDavid Tardon
Change-Id: Iec611290770ae0393eb787a3883bb22a12340b0a
2015-04-22zlib is not needed anymoreDavid Tardon
Change-Id: I7b13cbf041841236aa4218837d6ed4f2364196ce
2015-02-27For Clang -fsanitize=vptr use -fvisibility-ms-compat, not -fvisibility=hiddenStephan Bergmann
As discussed in b4f6b26b5a1a78fecfa95ec2eb7ac8b80495d8aa "SAL_DLLPUBLIC_RTTI for proper RTTI visibility for LLVM," RTTI-based -fsanitize= checks with Clang on Linux need special precautions to make RTTI symbols visible across DSOs. The approach taken there, as well as in 598d8194b0ea1a64e0ebba28a86c128bafa57c7c "Visible function type RTTI for Clang -fsanitize=function," was to add explicit SAL_DLLPUBLIC_RTTI annontations to relevant type definitions. However, for -fsanitize=vptr that would have required many more of those, so it appears easier to "misuse" -fsanitize-ms-compat in that case, which happens to give all RTTI symbols default visibility (while otherwise still honoring our SAL_DLLPUBLIC/PRIVATE annotations). The SAL_DLLPUBLIC_RTTI annotations from 598d8194b0ea1a64e0ebba28a86c128bafa57c7c "Visible function type RTTI for Clang -fsanitize=function" can likely be removed again. Change-Id: Ibeff7ab8c908111a7dc66ff0677204f112b24db8
2014-12-30Build external libs statically in the DISABLE_DYNLOADING caseTor Lillqvist
Fixes build for iOS. In theory, it is a bit unclear whether DISABLE_DYNLOADING means to 1) not build any dynamic libraries at all, not even of bundled 3rd-party libraries, or 2) not build any own dynamic libraries, including dynamically loaded UNO components, while still building 3rd-party libraries as dynamic. But in practice, a use case for the latter is nonexistent, nobody uses --disable-dynamic-loading in their autogen.input, and DISABLE_DYNLOADING is turned on automatically for iOS and Android. What we want for iOS, for an LO-based app, is to not build any dynamic libraries at all, but produce a single executable. Correspondingly for Android, at least currently, we want to produce a single dynamic library. Change-Id: I7af4c3e53b13439612bb57bbb0fc8b118bda96bd
2014-12-24upload librevenge 0.0.2David Tardon
Change-Id: Ie12b7ec9630d45e23fb11f12d2d4955855ae34cc
2014-11-10external: fortunately boost no longer requires config_host.mkMichael Stahl
Change-Id: I8f2176500bf620cd5e4cdf434e6122b6163b3e0f
2014-08-29Simplify some $ENABLE_DEBUG expressionsStephan Bergmann
Change-Id: I9f60fd317f3a2995a182d51d06059bd994cf837c
2014-08-29Pass --enable-debug down to some externalsStephan Bergmann
Change-Id: I3bb3c90142cbbd32877ba5e3d9070bc52ee76df9
2014-08-04fdo#82035 fix loader pathsDavid Tardon
Change-Id: Ibecd7a89491b487bec54e8a86edbb1b133cdb8f0
2014-06-17external/librevenge,libmwaw,libodfgen,libwps: fix self-linked symlinks build ↵Douglas Mencken
problem ...LibreOfficeDev.app/Contents/MacOS/librevenge-0.0.0.dylib: Too many levels of symbolic links (librevenge-0.0.0.dylib --> librevenge-0.0.0.dylib: broken symbolic link to librevenge-0.0.0.dylib) The reason for this is that symlink librevenge-0.0.dylib (UnpackedTarball/librevenge/src/lib/.libs/librevenge-0.0.dylib -> librevenge-0.0.0.dylib) is copied via cp --no-dereference, thus becoming linked to self. Change-Id: I4b918c35c594800fb2d7f84ee0ee9f2ff2a5fe14 Reviewed-on: https://gerrit.libreoffice.org/9783 Tested-by: David Tardon <dtardon@redhat.com> Reviewed-by: David Tardon <dtardon@redhat.com>
2014-06-03upload librevenge 0.0.1David Tardon
Change-Id: I10d457fe34a4e015d9a5e0fe92c27bdd1c7231be
2014-05-26rebase all import libsDavid Tardon
Change-Id: I9e1fc613816c943f4fb1033185e34e3acf317f1d
2014-05-25the other way around...David Tardon
Change-Id: I6aeaa95079e37e710e5b8b1b8ce24464e11f45bb
2014-05-25bundle librevengeDavid Tardon
Change-Id: Ic36c1670866545db2cf2f29867de7e5b0ad2d57d