summaryrefslogtreecommitdiff
path: root/svl
diff options
context:
space:
mode:
Diffstat (limited to 'svl')
-rw-r--r--svl/inc/svl/solar.hrc3
1 files changed, 1 insertions, 2 deletions
diff --git a/svl/inc/svl/solar.hrc b/svl/inc/svl/solar.hrc
index 973a738497e0..416563cf34e7 100644
--- a/svl/inc/svl/solar.hrc
+++ b/svl/inc/svl/solar.hrc
@@ -74,8 +74,7 @@
#define RID_OFA_START (RID_LIB_START+6900)
// RID_OFA_END (RID_LIB_START+7399)
-#define RID_GOODIES_START (RID_LIB_START+7400)
-// RID_GOODIES_END (RID_LIB_START+7449)
+// free: RID_LIB_START+7400 to +7449
#define RID_SVL_START (RID_LIB_START+7450)
// RID_SVL_END (RID_LIB_START+7899)
generated by cgit (git 2.34.1) at 2024-07-01 03:28:39 +0000
-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2021-12-03libxml2: use xml2-config dummy for internal buildJan-Marek Glogowski When building a static LO with --disable-dynloading on Linux, --without-system-libs failed for me. And it left me really puzzled: raptor configure failed and claimed it couldn't link libxml2. raptor's config.log showed missing math functions. xml2-config of LO's build is patched and it includes a -lm. The xml2-config in my chroot doesn't. But we explicitly pass the xml2-config for non-system-libxml2 build. Reading the configure from raptor didn't reveal a way, that it could somehow pick up the xml2-config from the chroot, but that code is autoconf-complex... When running "sh -x configure", it turned out the configure script actually picks up the LIBXML_* flags from the environment, which are set by LO's config_host.mk. These just add -lm for Android. So this adds a xml2-config.in "dummy", which overwrites the one from the libxml2 source and just echos LO's LIBXML_* values and it adds -lm for all DISABLE_DYNLOADING targets. Change-Id: Ia713cf80c8e7dc989cf23c224e7a0f7ea1210a87 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116409 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> 2020-11-24CVE-2020-25713 raptor2: malformed input file can lead to a segfaultCaolán McNamara due to an out of bounds array access in raptor_xml_writer_start_element_common use a better fix than the initial suggestion See: https: //bugs.mageia.org/show_bug.cgi?id=27605 https: //www.openwall.com/lists/oss-security/2020/11/13/1 Change-Id: I9203904755b0e4ac98ae1e39942fd6f616c1efff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106488 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Caolán McNamara <caolanm@redhat.com> 2020-11-23CVE-2020-25713 raptor2: malformed input file can lead to a segfaultCaolán McNamara due to an out of bounds array access in raptor_xml_writer_start_element_common See: https://bugs.mageia.org/show_bug.cgi?id=27605 https://www.openwall.com/lists/oss-security/2020/11/13/1 Change-Id: Ida4783a61412ffce868eacf81310da338d3e2df1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106423 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> 2020-09-03external/redland: Honour LIBXML_CFLAGS/LIBS in raptor's configureStephan Bergmann I ran into this issue with a somewhat special setup on macOS, with both Xcode 11 and Xcode 12 beta installed, and > xcode-select -s /Applications/Xcode-beta.app/Contents/Developer and > CC/CXX=... -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk ... to make the LO build use the latest SDK from Xcode 12 beta. (And with implicit --with-system-libxml, and with recent Clang 12 trunk.) However, even though raptor's configure receives our LIBXML_CFLAGS/LIBS env vars from config_host.mk, it always overrides them with output from some $XML_CONFIG tool. For whatever reason, in my setup that caused raptor's LIBXML_CFLAGS to be set to > -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include (And a similar reference to that /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk in LIBXML_LIBS. That MacOSX.sdk directory symlinks to some /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk. I don't know about that /Library/Developer/CommandLineTools/SDKs tree, but it smells like it is maintained by Xcode and not properly adapted for my Xcode 12 beta install.) Anyway, that LIBXML_CFLAGS ends up on raptor's compiler command lines, causing them to contain > ... -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk ... -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include ... so that something like > #include <stdio.h> in workdir/UnpackedTarball/raptor/src/raptor_parse.c will include > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h rather than > /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk/usr/include/stdio.h and consider the former not to be a system header, and thus emit warnings/errors like > In file included from raptor_parse.c:30: > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:220:5: error: 'TARGET_OS_EMBEDDED' is not defined, evaluates to 0 [-Werror,-Wundef-prefix=TARGET_OS_] > #if TARGET_OS_EMBEDDED > ^ that it would suppress from system headers. Raptor's configure appears to always override LIBXML_CFLAGS/LIBS since <https://github.com/dajobe/raptor/commit/ 7da03ba5cd6e45ea41afebd4955acf6e96e9d622> "Switch libxml and libcurl to use PKG_PROG_PKG_CONFIG and PKG_CHECK_MODULES", which looks like a bug to me. (Trying to prevent that code from being executed by passing in --without-xml2-config, similar to the existing --without-xslt-config in external/redland/ExternalProject_raptor.mk, would fail with > configure: error: libxml2 is not available - please get it from http://xmlsoft.org/ from raptor's configure, apparently suppressing libxml2 detection altogether.) Change-Id: I5f2813e849bb61c0af48df0579abe87d3671185b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101991 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2017-11-08redland: update autoconf configs the gbuild wayDavid Tardon Change-Id: I8a46a2ee60bb028c7fd9edcfdcd389813498ba9b 2017-06-13iOS, patch redlandjan Iversen Support for arm64 Change-Id: Id9f89452174bac4acb8d5b7dd3e23d91c2b2acf1 2017-05-02Make some externals' libtool copies cope with -mllvmStephan Bergmann ...as needed e.g. for <https://bugs.llvm.org/show_bug.cgi?id=32349> "r294897 + NewGVN cause build failure with LibreOffice", by applying <http://git.savannah.gnu.org/cgit/libtool.git/commit/ ?id=d9a35fe9d3508b5c0d56e7f2ec80fc05e8415fa3> "libtool: Discard '-mllvm $arg' options when linking." Change-Id: Id2afc3c8af3c6c9595e7cb33cef5084a74f78cb0 2017-04-19redland: add raptor patch to fix some bugsMichael Stahl Change-Id: I4e3db61fdfe0b984d36b4f67f8e891da48f79ddb 2017-02-10Remove MinGW supportStephan Bergmann In OOo times, there'd originally been efforts to allow building on Windows with MinGW. Later, in LO times, this has been shifted to an attempt of cross- compiling for Windows on Linux. That attempt can be considered abandoned, and the relevant code rotting. Due to this heritage, there are now three kinds of MinGW-specific code in LO: * Code from the original OOo native Windows effort that is no longer relevant for the LO cross-compilation effort, but has never been removed properly. * Code from the original OOo native Windows effort that is re-purposed for the LO cross-compilation effort. * Code that has been added specifially for the LO cross-compilation effort. All three kinds of code are removed. (An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing --with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.) Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568 Reviewed-on: https://gerrit.libreoffice.org/34127 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2016-08-26redland: upgrade raptor to 2.0.15, rasqal to 0.9.33, redland to 1.0.17:Michael Stahl - drop rasqal-pkgconfig.patch.1: merged upstream - drop most of rasqal-msvc.patch.1: merged upstream - drop redland-query-rasqal-avoid-assert.patch.1: merged upstream - drop redland-pkgconfig.patch.1: merged upstream Change-Id: I4f03bed5fc5c4b30151c0c532572e438681da041 Reviewed-on: https://gerrit.libreoffice.org/28416 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com> 2016-02-15external/redland: Defend against Yocto's broken xml2-configStephan Bergmann ...which is hard-coded to fail with echo '--should-not-have-used-/usr/bin/xml2-config' exit 1 Change-Id: Ic358e7d494f01f67c1469c4add080d775525ebb6 2015-06-12Fix Linux RPATH of various external modulesStephan Bergmann ...as discussed in 371cc81bd9ccbfbed25f810e70899c044280349e "external/liborcus: Fix Linux RPATH:" * When an external module produces multiple libraries (that we all install) that depend on each other, they need to contain $ORIGIN in RPATH (strictly speaking, those that do not depend on any other libraries from the module would not need that, but it is harmless and easier to do that way). * When an external module's libraries depend on other external modules' libraries, and (at least some of) those other external modules are not configuread as --with-system-*, they need to contain $ORIGIN in RPATH (again, for simplicity, some libraries may get that even if they would not strictly need it). * Try to outsmart the external modules' libtool instances to not add (ultimately bogus) paths to RPATH for dependencies on libraries from external modules (either from the same module, or from anohter module not configured as --with-system-*). The only time we do not outsmart libtool, and instead rely on it (hopefully?) doing the right thing is when a given external modules' libraries depend on libraries from excatly one other external module, and the latter is configured as --with-system-*. * That outsmarting means that if an external library depends both on external libraries provided by modules not configured as --with-system-* (so RPATH contains $ORIGIN, and the outsmarting is not suppressed) and on external libraries provided by modules configured as --with-system-*: Then if the latter are in unusual locations on the system that would require an RPATH entry (which might be provided via the corresponding "pkg-config --libs", say, and presumably would be honoured by libtool if we did not outsmart it), then those paths are now erroneously missing from RPATH. * That outsmarting also causes linking of some utility applications in module redland to fail, but those are ultimately unused, so cut them off by patching their respective sub-directory Makefile.in. Change-Id: Iec05b3568fbcf04987018322c328b769ae4f5dab 2015-01-09external/redland: Work around -fsanitize=nonnull-attributeStephan Bergmann Change-Id: Ibffc44da6e9d6fb02d43d8a2b7e143ff994d76a8 2013-11-04fdo#70393: move redland to a subdir of externalKhaled Hosny Change-Id: Ia857f943b8f2915c857ec4c9fa363760699e5206 Reviewed-on: https://gerrit.libreoffice.org/6551 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>