summaryrefslogtreecommitdiffstats
path: root/external/librevenge
Commit message (Collapse)AuthorAgeFilesLines
* WASM: add initial support for Emscripten cross buildJan-Marek Glogowski2021-05-051-1/+1
| | | | | | | | | | | | | | - configure with: - --host=wasm64-local-emscripten - had to make a few externals optional, so adding: - --disable-nss - --disable-cmis - --disable-curl Change-Id: I48d1c73d2675ad2e2beaf2c341578199efbd24ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111130 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
* GBUILD_TRACE, support for finding out where the build time is spentLuboš Luňák2020-02-161-0/+2
| | | | | | | | | | See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
* Remove legacy NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY supportStephan Bergmann2019-09-202-17/+0
| | | | | | | | | | | | | | | ...for ASan/UBSan builds using Clang older than current trunk twoards Clang 9, as announced at <https://lists.freedesktop.org/archives/libreoffice/2019-May/082654.html> "Re: [Libreoffice-commits] core.git: The -fvisibility-ms-compat hack is no longer needed for UBSan on Linux...". (And drop the no longer needed solenv/sanitizers/asan-suppressions, which people might still reference from their ASAN_OPTIONS.) Change-Id: Iedc0c5955366d2cbe7dc847990e2b1576750e85b Reviewed-on: https://gerrit.libreoffice.org/72493 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* disable warnings in external libsLuboš Luňák2019-05-241-1/+1
| | | | | | | | | | As in, really disable, so that they do not even show. This moreover avoids tons of D9025 warnings from MSVC about overriding -W4 with -w. Change-Id: Ia2e72fd72d883d91bdd89e467ee42f259e2ae033 Reviewed-on: https://gerrit.libreoffice.org/72899 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
* The -fvisibility-ms-compat hack is no longer needed for UBSan on Linux...Stephan Bergmann2019-05-031-3/+1
| | | | | | | | | | | | | | | | | | | | | | | ...with latest Clang trunk towards Clang 9. All the no-longer necessary hacks are made conditional on new NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY, which is still set for UBSan builds with older Clang on Linux (but which should eventually be purged). Various classes needed additional SAL_DLLPUBLIC_RTTI annotations, as building with UBSan instrumentation can generate references to RTTI symbols from additional places like outside a dynamic library that used to hide those symbols by default (but used to not hide them for old UBSan builds thanks to the -fvisibility-ms-compat hack). The odr-violation suppressions in solenv/sanitizers/asan-suppressions (which is not referenced from anywhere in the code base, but meant to be included in an ASan/UBSan build's ASAN_OPTIONS env var) are also no longer needed when NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY is false. Change-Id: I24ec3e388b0cbab50dbe2bf008d9569bff7bf25a Reviewed-on: https://gerrit.libreoffice.org/70829 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Fix libtool RPATH outsmarting hack for external/librevengeStephan Bergmann2019-03-061-1/+2
| | | | | | | | | | | | | | | After the blind fix attempt of 490f07cf7235ab3c5dc4be13c53832e3266bd8e6 "Extend libtool RPATH outsmarting hack to external/librevenge", appears that <https://ci.libreoffice.org/job/lo_daily_update_gandalf/596/> also needs runpath_var=LD_RUN_PATH to be reset. (See also how <https://src.fedoraproject.org/cgit/rpms/librevenge.git/tree/librevenge.spec ?id=4960d4c6c190885b20f56ce9ee1ad2ad92b87021#n46> addresses the same problem for Fedora builds of librevenge.) Change-Id: I5cff145605cd05a8b87360c1edc3574e3364139b Reviewed-on: https://gerrit.libreoffice.org/68800 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Extend libtool RPATH outsmarting hack to external/librevengeStephan Bergmann2018-12-112-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | (See 1d028d4783da69c5c0e6e0b59e0f8ac55eb9d2b1 "Fix Linux RPATH of various external modules" for the similar patches to other external projects.) This is a blind fix attempt for <https://ci.libreoffice.org/job/lo_daily_update_gandalf/559/console> > /lo/home/tdf/lode/jenkins/workspace/lo_daily_update_gandalf/instdir/program/librevenge-0.0-lo.so.0 has unexpected RPATH 0x000000000000001d (RUNPATH) Library runpath: [/opt/rh/devtoolset-7/root/usr/lib/../lib64] [...] > /lo/home/tdf/lode/jenkins/workspace/lo_daily_update_gandalf/postprocess/CustomTarget_check_dynamic_objects.mk:20: recipe for target '/lo/home/tdf/lode/jenkins/workspace/lo_daily_update_gandalf/workdir/CustomTarget/postprocess/check_dynamic_objects/check.done' failed after ed81fe44d4e6b36c4c61a22e9e28a3a94fef9238 "Enabling Developer Toolset 7 for Jenkins' remaining GCC master jobs" enabled GCC 8 at gandalf's /opt/rh/devtoolset-7/root/ (which is at the same location as a CentOS Developer Toolset 7 special GCC 7, but is actually a plain GCC 8, cf. <https://lists.freedesktop.org/archives/libreoffice/2018-December/081544.html> "Re: Compiler baselines") for the lo_daily_update_gandalf job. Presumably libtool added to RPATH a path to find that GCC 8 installation's /opt/rh/devtoolset-7/root/usr/lib64/libstdc++.so.6. Change-Id: I18a88b2dcdfcaf2e2d36d5ee1b41ce865e4ac34e Reviewed-on: https://gerrit.libreoffice.org/64943 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* librevenge: pass optimization flags to configureDavid Tardon2017-10-281-1/+2
| | | | | | | Change-Id: I27220fe91299ccee1e89df1b865dd1de550a01a0 Reviewed-on: https://gerrit.libreoffice.org/43970 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
* use gbuild way to update config.*, continuedDavid Tardon2017-10-102-21/+2
| | | | | | | Change-Id: I9abf1742c213f47c576ffbb7dafd33087f7037e5 Reviewed-on: https://gerrit.libreoffice.org/43307 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
* iOS patch librevengejan Iversen2017-06-122-0/+21
| | | | | | Support for arm64 Change-Id: Ibba1a9486b8eaee4bf3c0cf673dd4cc112d084e0
* configure: set BOOST_CPPFLAGS also in --without-system-boost caseMichael Stahl2016-05-301-1/+1
| | | | | | Simplify the makefiles. Change-Id: Ia695961e936e4a1ffdaff73eb56adc3c3905ed0c
* upload librevenge 0.0.3David Tardon2015-12-253-4/+3
| | | | Change-Id: I8f2c09b70679aabb5e5f56334e6ba9eedd2d78e1
* Generalize COM_GCC_IS_CLANG -> COM_IS_CLANGStephan Bergmann2015-11-121-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>
* blind attempt to fix lcovDavid Tardon2015-09-171-1/+1
| | | | Change-Id: If8d6c8da1be1e540d641f20ac90e7877feae27be
* core: fix build with system boost 1.59David Ostrovsky2015-09-011-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>
* gbuild/config stop using VERBOSE, use only verbose=tNorbert Thiebaud2015-08-111-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>
* librevenge bundled soname patchAndras Timar2015-08-073-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>
* use $(DISABLE_DYNLOADING) consistentlyDavid Tardon2015-06-051-1/+1
| | | | Change-Id: Iec611290770ae0393eb787a3883bb22a12340b0a
* zlib is not needed anymoreDavid Tardon2015-04-221-2/+0
| | | | Change-Id: I7b13cbf041841236aa4218837d6ed4f2364196ce
* For Clang -fsanitize=vptr use -fvisibility-ms-compat, not -fvisibility=hiddenStephan Bergmann2015-02-272-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
* Build external libs statically in the DISABLE_DYNLOADING caseTor Lillqvist2014-12-301-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
* upload librevenge 0.0.2David Tardon2014-12-241-1/+1
| | | | Change-Id: Ie12b7ec9630d45e23fb11f12d2d4955855ae34cc
* external: fortunately boost no longer requires config_host.mkMichael Stahl2014-11-101-1/+1
| | | | Change-Id: I8f2176500bf620cd5e4cdf434e6122b6163b3e0f
* Simplify some $ENABLE_DEBUG expressionsStephan Bergmann2014-08-291-1/+1
| | | | Change-Id: I9f60fd317f3a2995a182d51d06059bd994cf837c
* Pass --enable-debug down to some externalsStephan Bergmann2014-08-291-1/+1
| | | | Change-Id: I3bb3c90142cbbd32877ba5e3d9070bc52ee76df9
* fdo#82035 fix loader pathsDavid Tardon2014-08-041-0/+4
| | | | Change-Id: Ibecd7a89491b487bec54e8a86edbb1b133cdb8f0
* external/librevenge,libmwaw,libodfgen,libwps: fix self-linked symlinks build ↵Douglas Mencken2014-06-171-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>
* upload librevenge 0.0.1David Tardon2014-06-034-811/+1
| | | | Change-Id: I10d457fe34a4e015d9a5e0fe92c27bdd1c7231be
* rebase all import libsDavid Tardon2014-05-262-0/+54
| | | | Change-Id: I9e1fc613816c943f4fb1033185e34e3acf317f1d
* the other way around...David Tardon2014-05-251-1/+1
| | | | Change-Id: I6aeaa95079e37e710e5b8b1b8ce24464e11f45bb
* bundle librevengeDavid Tardon2014-05-258-0/+927
Change-Id: Ic36c1670866545db2cf2f29867de7e5b0ad2d57d
generated by cgit (git 2.34.1) at 2024-05-12 04:53:13 +0000