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>
When --enable-fuzz-options is given, those --enable or --with options
that are separately so marked, and have not been specified explicitly
at the configure command line (i.e. typically from autogen.input), are
randomly set to either yes or no.
This functionality is useful to make sure configure options don't
bit-rot by randomly exercising uncommon settings and combinations.
To enable fuzzing for an option, use libo_FUZZ_ARG_WITH instead of
AC_ARG_WITH, or libo_FUZZ_ARG_ENABLE instead of AC_ARG_ENABLE.
Also handle two cases of incompatibilty of options discovered by using
--enable-fuzz-options. In general using incompatible options should
cause an AC_MSG_ERROR(), but when one of the options in question has
been set by fuzzing, it's simplest to just reset it to the compatible
value.
Obviously this is highly experimental.
Change-Id: I76d250c148892951a7fda25ba4164de8bc693a26
The goal is to avoid build breakage by pkg-config or whatever helpfully
putting default paths like -L/usr/lib64 into *_LIBS, which is entirely
useless since ld searches there anyway but may override other -L that
occur later on the command line for LO bundled externals.
On a Fedora 22 system, at least these variales were affected:
CLUCENE_LIBS FIREBIRD_LIBS KDE4_LIBS POSTGRESQL_LIB BOOST_LDFLAGS
Change-Id: Ie55f65c3ae29a125f16871d95ad8b716abf5c982
Reviewed-on: https://gerrit.libreoffice.org/19784
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
The assumption that all configure variables had been normalized to
TRUE/<empty> turned out not to hold; convert a bit more in that
direction.
(regression from 4af38b099c)
Change-Id: I2127c515e8a833a07c9b26ed9d693ce5a1853fe4
The standard Boost convention is for them to be called libboost_date_time and
libboost_system (with apropriate suffix then depending on type).
Did not touch the libboostthread library we build for Windows.
Add the ax_boost_thread.m4 file for completeness and possible use.
Document where the ax_boost*.m4 files come from.
Change-Id: Ib49bee71398d62c9760a1f8fd5c46be9f3400430
On --disable-openssl, the bundled neon library
will link against GNUTLS + gcrypt instead of
OpenSSL.
Change-Id: I5b3f09cd1003aefde0478aaab026536c962212c4
Reviewed-on: https://gerrit.libreoffice.org/3330
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
one variable to find them,
one variable to deliver them all and into filelist put them,
in $INSTDIR where the installer searches.
Change-Id: I989f578f0ed6f9ef9167522249b36d95c15bfd1b
Consistently set WPD_CFLAGS/WPD_LIBS etc. in that case, with luck not
breaking anything else in the process due to newly set FOO_CFLAGS/LIBS.
Change-Id: I56bc6b86821b77c0c376d06b629646ada1ea0339
- a >12.000 LOC configure.ac is more than enough for everybody
- removing some 100 lines cant hurt
- the SYSTEM_LIBCDR=$SYSTEM_CDR stuff should be removed in a later step,
by renaming them in the build
Change-Id: I5c065c5c341561258800a124b0fc1f40b3d59211
The idea is to use libo_MINGW_CHECK_DLL for libs that must be available
(typically that would be the "main" library, e.g., libxml2 or libcurl)
and libo_MINGW_TRY_DLL for possible dependencies (that may not be the
same on different systems). All further references to the dlls are
exclusively through the configured variables or defines set from these
variables (e.g., instead of hardcoding libxml2-2.dll, use
$(MINGW_LIBXML2_DLL)).
The macros are documented in m4/mingw.m4 .
Files that must be changed when adding a new dll:
* configure.in
* config_host.mk.in
* external/mingw-dlls/makefile.mk
* scp2/source/ooo/makefile.mk
* scp2/source/ooo/mingw_dlls.scp
Hardcoding dll names from SuSE Linux in configure.in is not good,
because they might be slightly different on other systems (notably
Fedora :-), or the libraries might be compiled with different
dependencies.
Andrea Gelmini