On 19/04/13 02:00, Markus Mohrhard wrote:
Hey,
is there anything speaking against building external libraries in the
dbgutil case with symbols and without optimization? Ideally IMHO we
should even build c++ libraries with GLIBCXX_DEBUG.
we should definitely build everything with debug symbols in a dbgutil
build. i don't really have an opinion on optimizations.
we already build the 2 externals where it matters (cppunit/liborcus)
with _GLIBCXX_DEBUG; i'd say it's probably a good idea to use it for all
externals but in case a library has never been build with it we should
be prepared to patch some issues in it, i.e. it needs testing.
there are also more debug modes in some externals, similar to our own
--enable-dbgutil with additional assertions; there may be some among
them that make sense to enable but there are probably others that don't
make sense, e.g. iirc there was some XML library that dumps out every
element it parses on stderr which is a bit too much verbosity.
for example python has --with-pydebug, which we actually use currently
when building against MSVC debug runtimes but not on other platforms.
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.