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
Esp. since LO links against a liborcus.a, this would otherwise cause linker
warnings like
ld: warning: direct access in orcus::orcus_xml::read_file(char const*) to
global weak symbol boost::unordered_detail::prime_list_template<unsigned
long>::value means the weak symbol cannot be overridden at runtime. This was
likely caused by different translation units being compiled with different
visibility settings.
on Mac OS X (where HAVE_GCC_VISIBILITY_FEATURE is unset).
Change-Id: I6f09b61aa77b6d5c3f8b53407d8faff4fb3bb8a1
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.
