summaryrefslogtreecommitdiff
path: root/external/librevenge
AgeCommit message (Collapse)AuthorFilesLines
2016-05-30configure: set BOOST_CPPFLAGS also in --without-system-boost caseMichael Stahl1-1/+1
Simplify the makefiles. Change-Id: Ia695961e936e4a1ffdaff73eb56adc3c3905ed0c
2015-12-25upload librevenge 0.0.3David Tardon3-4/+3
Change-Id: I8f2c09b70679aabb5e5f56334e6ba9eedd2d78e1
2015-11-12Generalize COM_GCC_IS_CLANG -> COM_IS_CLANGStephan Bergmann1-1/+1
...in anticipation of building with clang-cl.exe on Windows Change-Id: I1d723c9d3b5ca8a2bc6b27ef0189a7b053581398 Reviewed-on: https://gerrit.libreoffice.org/19928 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2015-09-17blind attempt to fix lcovDavid Tardon1-1/+1
Change-Id: If8d6c8da1be1e540d641f20ac90e7877feae27be
2015-09-01core: fix build with system boost 1.59David Ostrovsky1-1/+2
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 Thiebaud1-1/+1
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 Timar3-1/+20
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 Tardon1-1/+1
Change-Id: Iec611290770ae0393eb787a3883bb22a12340b0a
2015-04-22zlib is not needed anymoreDavid Tardon1-2/+0
Change-Id: I7b13cbf041841236aa4218837d6ed4f2364196ce
2015-02-27For Clang -fsanitize=vptr use -fvisibility-ms-compat, not -fvisibility=hiddenStephan Bergmann2-1/+20
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 Lillqvist1-2/+3
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 Tardon1-1/+1
Change-Id: Ie12b7ec9630d45e23fb11f12d2d4955855ae34cc
2014-11-10external: fortunately boost no longer requires config_host.mkMichael Stahl1-1/+1
Change-Id: I8f2176500bf620cd5e4cdf434e6122b6163b3e0f
2014-08-29Simplify some $ENABLE_DEBUG expressionsStephan Bergmann1-1/+1
Change-Id: I9f60fd317f3a2995a182d51d06059bd994cf837c
2014-08-29Pass --enable-debug down to some externalsStephan Bergmann1-1/+1
Change-Id: I3bb3c90142cbbd32877ba5e3d9070bc52ee76df9
2014-08-04fdo#82035 fix loader pathsDavid Tardon1-0/+4
Change-Id: Ibecd7a89491b487bec54e8a86edbb1b133cdb8f0
2014-06-17external/librevenge,libmwaw,libodfgen,libwps: fix self-linked symlinks build ↵Douglas Mencken1-1/+1
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 Tardon4-811/+1
Change-Id: I10d457fe34a4e015d9a5e0fe92c27bdd1c7231be
2014-05-26rebase all import libsDavid Tardon2-0/+54
Change-Id: I9e1fc613816c943f4fb1033185e34e3acf317f1d
2014-05-25the other way around...David Tardon1-1/+1
Change-Id: I6aeaa95079e37e710e5b8b1b8ce24464e11f45bb
2014-05-25bundle librevengeDavid Tardon8-0/+927
Change-Id: Ic36c1670866545db2cf2f29867de7e5b0ad2d57d
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-10 05:00:03 +0000