No idea why we just provided the platform flags when cross-
compiling. In the curious case, where the host platform is
detected as x86_64-pc-mingw32 per default and we actually
want to override it with x86_64-pc-cygwin, we don't do a
cross compile, but must override the host platform.
But there is additional special handling needed for the omitted
cross-platform build in the special case of --host=i686-pc-cygwin
and --build=x86_64-pc-cygwin, where we deliberatly ignore cross
building; Windows is already a slow build, so try to keep this
optimization (AMD64 can execute x86 binaries).
There is the theoretical case, where the externals config.guess
would have detected something else and that "magically" even
worked, while the LO detected triplet would fail, but this
should be fixed in the external in any way.
Change-Id: Ib7a9719e0e406fe90334b7611dc3f01b51692bfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129153
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
...as now reported when building with recent trunk GCC/libstdc++ on Linux:
> In file included from WPXContentListener.cpp:26:
> In file included from ./WPXContentListener.h:29:
> ./WPXTable.h:56:31: error: unknown type name 'size_t'; did you mean 'std::size_t'?
> const WPXTableCell *getCell(size_t i, size_t j)
> ^~~~~~
> std::size_t
Change-Id: Ic20240f01c7b0305cb87ababf53a3aaf66072d61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105324
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
I think this is all external libs where it makes sense for them
to have their own PCH and be worth it. Maybe some smaller externals
can also use the common system PCH, but unfortunately many externals
use all kinds of defines that affect system headers, which is
a problem for the common system PCH.
Change-Id: I2c589ac55d93728daf3b158df110722e5f055d45
Reviewed-on: https://gerrit.libreoffice.org/80728
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
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>
...as discussed in 371cc81bd9 "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
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
Caolán McNamara