Age | Commit message (Collapse) | Author |
|
* drop libxslt-freebsd.patch.1
fixed in new upstream libtool
* drop libxslt-config-guess.patch.0
fixed in new upstream autoconf
* drop libxslt-android.patch
fixed in new upstream autoconf
* drop libxslt-configure.patch.1
fixed upstream
* drop libxslt-vc15.patch
fixed upstream
* drop second hunk of libxslt-vc10.patch
fixed upstream
* drop 0001-Fix-for-type-confusion-in-preprocessing-attributes.patch.1
fixed upstream
Change-Id: I7427725ed6c82da53de12c9e1676e6ce02fd6483
Reviewed-on: https://gerrit.libreoffice.org/25775
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
When Windows build is executed, cscript is used to execute JavaScript files.
This uses cscript from the system to execute *.js files. cscript is not
only capable of executing JavaScript, but also VBScript. Which engine to
run is usually determined by the file extension, except when any installed
program has added a registered association to the used file type. In that
case, the execution of cscript and thus the build fails. This can be prevented
by directly defining the script engine when calling cscript, using the
/e:javascript parameter for *.js targets.
Change-Id: If717b8ae5335acbe4f11c269d3c98a7247a135e6
Reviewed-on: https://gerrit.libreoffice.org/21717
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
libxslt shared library depends on libxml2 library, and for cases when
libxml2 is "external", just-compiled libxslt will have an entry like
/@.__________________________________________________URELIB/lib/libxml2.2.dylib
and the whole LibreOffice application will fail to run
Change-Id: Ifafbdab74151207597ba9bd2e3beb0b8c3aa3ab7
Reviewed-on: https://gerrit.libreoffice.org/20816
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I733cd21f6d8c7ea1e01f594d1483ad9c2043c188
|
|
Change-Id: Icb7f7cb20f5e2b200442bbc2d2bd4eb540170045
Reviewed-on: https://gerrit.libreoffice.org/16761
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
...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
|
|
The ../../../program/ links in the URE jar Class-Paths are a temporary kludge
(and juh.jar had lacked adaption for Mac OS X).
Change-Id: I2542d8a582866485dd61c05df3fc6b4b39a8403d
|
|
Hopefully this should fix up the most important external libraries.
Change-Id: I744cb5a2ce7fafb10852059050cf24589d6ca400
|
|
...to latest versions from <http://git.savannah.gnu.org/gitweb/?p=config.git;
a=blob_plain;f=config.guess;hb=HEAD> and <http://git.savannah.gnu.org/gitweb/?
p=config.git;a=blob_plain;f=config.sub;hb=HEAD>, for aarch64 support.
Change-Id: I99756c33652aa8e19c6a407260b5c49de140128e
|
|
Change-Id: I0523e49e640812be435ba4c97b1881ca253eb2ab
|
|
Change-Id: I4f4cecd95f87b9d37fa1b1a270cf554d7707aaa2
|
|
Change-Id: I0cc43cef91e3fcd82a3558a16ab0afbd4d56b141
|
|
Change-Id: Iffcc671ca41c5880579effe0786a3b4d3be0dab0
|
|
Change-Id: I1992f3fc150a4e205a2247e210ce8af91664982c
|
|
- from libxslt-configure.patch:
* drop config.sub Android stuff (obsolete)
* drop MinGW archive checks (obsolete)
* split out libxslt-config.patch.1
* split out libxslt-freebsd.patch.1
- drop libxslt-aix.patch:
presumably don't need special check for V7BETA since it's released now
- drop libxslt-mingw.patch (it's for msys build so obsolete)
- drop libxslt-win_manifest.patch:
this can just be passed on configure.js command line so no need for a patch
Change-Id: I8a2cad0a70a86ba1dffbe3c8fce60babb70a61f6
Reviewed-on: https://gerrit.libreoffice.org/6641
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I2bc45e4ba63f5faaee7389bcd9d7b3f563503186
|
|
Deliver all external libraries to INSTDIR directly.
Change-Id: I8d3e035e5cfa07bd0f53ee4a226c48d4b86a4032
|
|
Change-Id: I1324c8f21e31c69b9780136cc777e1aea3bc546e
|
|
Change-Id: I3067e3c819a4918e1d3c91dc0e0cfa3e4fc92b3d
|
|
Change-Id: I0ed69bcfee650ae403d793b27db4ad906132efed
|
|
Change-Id: Ibf6fd5c32a62752044e70961cf33b05fdcdce104
Reviewed-on: https://gerrit.libreoffice.org/6340
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|