Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


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.