moving staticlibs to workdir broke it since
520c7dc9e8860e506145e879182ca32853617097
Instead of copying the unzipped libs to another directory,
reference them from UnpackedTarball directory instead.
Change-Id: I711cae4305c6888bd923dcb09e51416cbe363377
Reviewed-on: https://gerrit.libreoffice.org/6191
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
Uses wrong package, fix it like 51ff75129c6b61d4f3ba31fa189b38bbf867910d,
thanks for adam_co for finding this problem.
Change-Id: Ic643a76b3e4504aa815cd76897287a1d7bb62569
..instead of .xcu files in solver/*/xml/registry
when running unittests and gengal.
Change-Id: I390a6c531d653acca7ef3379c49fe65fcb8f3c2a
Reviewed-on: https://gerrit.libreoffice.org/6057
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
It shouldn't be used for external libraries, not built by gbuild,
anyway, because it creates wrong dependency.
Change-Id: I889dccb1f934caef7f104d479dbe16185b8eeaf4
Add more FOO_FOR_BUILD variables and some gb_Foo_for_build functions.
Get rid of gb_INSTROOT and gb_DEVINSTALLROOT, just use INSTROOT.
Change-Id: Iee531b02d14fae41edb68ad589a5dec829a60255
Note: do NOT put file paths to static libraries into FOO_LIBS variables
that are passed to bundled externals that are built with --enable-static:
on Mac OS X this will result in .a archives that contain other .a
archives as entries, and trying to link those results in errors like:
ld: warning: ignoring file .../libodfgen-0.0.a, file was built for
archive which is not the architecture being linked (i386)
Change-Id: If2c5a458058e4da76f80b3643e55b489d1edee24
Call and link executables directly in INSTDIR.
- gb_Library_get_target is now same as the gb_LinkTarget_get_target
- disable gb_Library_add_auxtarget, no auxtargets need to be copied
- adjust paths of all external executables to OUTDIR_FOR_BUILD for now
- use lazy assignment instead of := in AllLangResTarget because it's
read before Executable
- link.exe generates an import library for lots of executables
because they export symbols, especially since commit
0ffab9363d527d55b12b9b09d7136ca1c9d171e0
"force 'main' to always be DLLPUBLIC."
Change-Id: I3e1ee7425dd430bb83c7cd59e265869a0541b38d
... so that custom targets in i18npool run. Can't remember if that is a
pre-existing problem or caused by one of my changes.
Change-Id: Ic0aa1f2b8600f4951d30a5ac6f3ade1a4fb2d313
We now load OpenCL library dynmically at run-time as needed. So there
is no build time dependency on any OpenCL implementations.
Change-Id: I214399060398a7c5e37b9a254147ccc2834e7866
Introduced gb_INSTROOT, which is the same as $(INSTDIR) except for Mac OS X,
where it is $(INSTDIR)/LibreOffice.app/Contents. Most stuff ends up there (so
most occurrences of $(INSTDIR) have been replaced with $(gb_INSTROOT)), but SDK-
related stuff goes to $(INSTDIR)/$(gb_Package_SDKDIRNAME). (And
GeneratedPackage needed to be made more flexible, to allow for packages that go
into either of those two places.)
For Android and iOS, gb_INSTROOT probably still needs to be set.
The most obvious missing thing yet to make instdir work for Mac OS X is the
instdir/*/LibreOffice.app/Contents/ure/ vs.
instdir/*/LibreOffice.app/Contents/ure-link/ split.
Change-Id: I4478edd27b14c92c96d92d5169bdca3ec50d78f5
Lots of stuff still either ended up in the wrong place, or was looked up from
the wrong place, or both. Fix most cases.
Change-Id: I06ebbce207c219f3cd82b4387dd9b3fdb83420d4
neon 0.30.0 has added support for SSPI (author of the commit is kso,
which sounds familiar :-), so NE_FEATURE_SSPI is defined, but the
signature of ne_auth_creds remains the same as before. That means that
build with system neon 0.30.0 fails...
They are not use by default since 2011, and non of the distro configs
uses --without-system-xextensions-headers.
Change-Id: I51e88796c22b1b3d0854c3ec1db15fcab720a079
Reviewed-on: https://gerrit.libreoffice.org/5175
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
Raptor already sets up all 4 error handlers in xmlSAXHandler so why it
would need the global ones in addition to that is a mystery anyway.
Messing with libxml2's globals can only cause trouble.
Change-Id: I2935efe5c4cd75d48cc4ecdeaa8437e91b48349e
