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
Modify our patches as necessary to match the updated boost sources. Drop
patches for which corresponding (or even identical) changes already are
present. Add a new boostsystem static library and use it in two places.
Change-Id: Ib59558feb56dab87a69c91b38caca8e7a9e9a22e
Also, for clarity, sort the list of platforms for which it is needed
(those where we use the GNU C++ library).
Change-Id: I55463f248ee08f97c085610d72fa688657ba36e6
I could not get it to build using the project files and VS2012...
With one additional patch to drop the use of dllimport in env.hpp, the
"gcc-wrapper" way builds fine for me, using VS2012.
It is not necessary to specify the dllimport attribute for functions
imported from a DLL. Specifying dllimport if the library actually is a
static library (as it is here) leads to linking errors.
The way the ifdefs and -D options were set up here, the utility and/or
test programs that are built as part of the liborcus build were
compiled using dllimport, and thus failed to link. So just don't
bother with dllimport.
This reverts commit 58b4cd934fd28b796dc12590f33971dd32ec95ee.
Change-Id: I2ffc90d47ae018a9a14b1c6d07fb0a225ce10d6d
Also hopefully make the environment variable setting on the configure commmand
line saner and working as intended for all platforms where relevant.
It doesn't work to set and append to an environment variable in one same
command like CPPFLAGS=something CPPFLAGS+=more ./configure ...
Change-Id: Ifb3fb6748d59388124b9987a1db3cab15ebaf757
...at least unless configured --without-gnumeric-filter, see its configure.ac:
"The gnumeric import filter depends on zLib."
Change-Id: Ied3fb0119978ed484c5e0668cd6a949b448e1ee0
Surely if we need to use -D_GLIBCXX_HAS_GTHREADS on Android we should do that
somehow globally then and not just here in liborcus? But I haven't seen any
compilation errors caused by a lack of that? (Except, if memory serves me
right, for the Android on MIPS platform, but I haven't tried building that for
ages.)
And anyway, setting CPPFLAGS to one value in the environment for configure and
passing a CPPFLAGS setting on the configure command line (in the
--enable-dbgutil case) surely is pointless.
This reverts 84374b2d4c44a5c81277ebc18eadd632cd8497b5
Change-Id: I2a280bb24dc0a557c825070866e1969c3176fc3f
ExternalProject usually involve a configure and a make
step that produce a bunch of output usually irrelevant
including a large number of warning and other mess.
now that everything is pretty much in tail_build
these output get interleaved with useful output from
the build of the product and actually drown them in a logorrhea
of messy noise.
This store the output of external modules in a log file
and only print them as a whole if the module failed do build.
on a non-verbose build.
Change-Id: I3abfcccd6d16821a9e061a71e031b427cc283647
Reviewed-on: https://gerrit.libreoffice.org/2304
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
...though it would arguably be better to just pass along --with-boost=... where
applicable. (liborcus' orcus-xml-dump links against -lboost_system, so needs
BOOST_LDFLAGS passed in in addition to BOOST_CPPFLAGS.)
Change-Id: I6467d0f453d68494b75559a7eb61f865f9513b50
- do not use gb_UnpackedTarball_copy_header_files for boost
- adapt the optimization in concat-deps.c for new path
- use boost_headers in all LinkTargets that require it
- add explicit include paths to mysqlc, mysqlcppconn, libvisio, liborcus
Change-Id: I0c43e73ed43cc9d2e6bce8faf55e992d655a0bb9
The /p:PlatformToolset=v110 /p:VisualStudioVersion=11.0 options are
needed to indicate that we want that. Otherwise MSBuild, when
presented with a .vcxproj file created by VS2010, will assume it is
the 2010 compiler that should be used. This will then lead to link
errors pointing outthe incompatibility when linking the static
liborcus into the scfilt DLL.
Rationale:
- it is advised to use max-jobs and num-cpus with the same value in wiki
- max-jobs was used only for lcms2 and few gbuild
modules outside of tail_build anyway.
Also fixes:
- really use CHECK_PARALLELISM when meant to
- EXTMAXPROCESS is not defined in gbuild;
use parent's jobservers in sub-make where possible
Change-Id: I501de732d223ce0c935081bd1d73da611d16ee88
Reviewed-on: https://gerrit.libreoffice.org/930
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
Causes way too much problems with the tinderboxes, thanks to -Werror
getting passed to the liborcus configury, and liborcus apparently is
quite -Werror-unclean.
Thus also revert the initial fixes for those WaEs. (Many more would be
needed, it seems. I rather leave it to Kohei to make upstream liborcus
warning-free.
This reverts commit 083fa89dd8f894f9cd0ef217a900fab777db9f2a.
This reverts commit 7e871bbaf7b208dd884528259211385b8074da39.
This reverts commit 21b5706f83edecad8cd3d0ab3ce5110b82e75a46.
This reverts commit bed5557e8bdfe5c698a45a4cc82619a7c22de001.
