| Age | Commit message (Collapse) | Author |
|---|
|
...otherwise, at least with some --with-system-boost versions and C++11
compilers, like with Fedora's boost-1.50.0-4.fc18.x86_64 and
gcc-c++-4.7.2-8.fc18.x86_64, using this to copy-construct an instance of
boost::unordered::detail::ptr_node<std::pair<rtl::OUString,Bootstrap_Impl*>> in
the call to p_bootstrap_map->insert(...) in rtl_bootstrap_args_open
(sal/rtl/source/bootstrap.cxx) would memcopy the ptr_node and fail to call
rtl_uString_acquire, leading to memory corruption later on when
rtl_uString_release is called one time too often.
It is not entirely clear to me whether this is a shortcoming of the given Boost
version, but this patch solves the problem and brings rtl::Allocator::construct
in line with the (changed) Allocator requirements of C++11 anyway.
The problem potentially lurks with every use of rtl::Allocator, but only showed
now begining with LO 4.0 where e5111574fd904b38a3980ca4ea3d21cfcb22dea6 "Revert
'sb140: sb140: #i116981# clean up memory upon exit'" re-introduced code into
rtl_bootstrap_args_open that inserts into a boost::unordered_map that uses
rtl::Allocator.
(cherry picked from commit c91d353872b7d4e1a39192bff1444b46cab6e5eb)
Conflicts:
config_host/config_global.h.in
...solved by resorting to the old -DHAVE_CXX11_PERFECT_FORWARDING logic spread
across various solenv/.../*.mk instead.
Change-Id: I3be22f59a8eb49d31458480c27f3ce15803c7fd4
Reviewed-on: https://gerrit.libreoffice.org/2166
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The STLport was only built for the benefit of old extensions on platforms that
once used it themselves (Linux x86, Solaris x86 and SPARC, Windows). We
deliberately break such old extensions for LO 4.0 by no longer shipping that
backwards-compatiblity cludge.
Keeps STLport listed in readlicense_oo/ because of
o3tl/inc/o3tl/compat_functionality.hxx.
Also removes GXX_INCLUDE_PATH, as that was only used by STLport (if at all?).
(cherry picked from commit 77d3777c8934171a9557a96872d020cf12443fb9, minus the
code that addressed Windows C4005 warnings -- which after all were due to
unrelated changes for PCH rather than this commit)
Conflicts:
postprocess/prj/build.lst
Change-Id: Ie138a219fbbc86fb5aaa7ea0b88cf349935d9829
|
|
Change-Id: I2214674181c137a312b0109e7d19a1fd2fc942be
|
|
By default a product (non-developer) build is done. Code is optimized and no debugging
information is included (may be overriden though, see below).
Developers should preferably build with --enable-dbgutil , or at least --enable-debug.
The --enable-symbols switch has been removed. Use explicit CFLAGS/CXXFLAGS/LDFLAGS instead
if needed.
With --enable-debug optimizations are turned off and debugging information is included
(in order to make it possible to examine the code in a debugger). Additionally assertions
and logging is enabled (see SAL_WARN/SAL_INFO documentation for details and better control).
This switch should primarily by used for occassional development (such as when it is needed
to debug one module in a non-debug build, see also 'make DEBUG=true' below).
Using --enable-dbgutil is the recommended developer option. In addition to --enable-debug
it also enables additional checks, such as debugging mode for STL or checking compiler
plugins. This switch may also enable additional logging from obsolete debugging tools
(which should be converted to SAL_WARN/SAL_INFO for better control). Note that this option
makes the build binary incompatible from a --disable-dbgutil build, so it is not possible
to mix them.
When using --enable-debug/--enable-dbgutil , the build is noticeably larger because of the included
debugging information (compiler -g option). When disk space is an issue (or the computer
is not very powerful), the --enable-selective-debuginfo option allow specifying where
the debugging information should or should not be used. The option takes a list of arguments,
where all means everything, - prepended means not to enable, / appended means everything
in the directory; there is no ordering, more specific overrides more general,
and disabling takes precedence). For example, --enable-selective-debuginfo="all -sw/ -Library_sc"
enables debugginfo for everything except for anything in the sw module and the sc library.
Explicitly specified CFLAGS/CXXFLAGS/LDFLAGS override optimization and debugging options
(can be now also passed to configure which will make the build system use them).
If in a non-debug build it is needed to temporary build something as a debug build,
'make DEBUG=true' temporarily works as if --enable-debug was specified. It also temporarily
overrides debuginfo disabled using --enable-selective-debuginfo.
Old code using old logging functionality also has a concept of a debug level, forced using
'make DBGLEVEL=2'. Using a debug level of 2 (or higher) enables additional logging output.
New code should use SAL_WARN/SAL_INFO and use extra areas for additional logging output
that can be selectively enabled/disabled using SAL_LOG variable.
(Some smaller parts of this design will be implemented by separate follow-up commits.)
Change-Id: Ia6420ee3c99c217ead648e8967165eed7f632258
|
|
Change-Id: I6ef6a7dea7a5f594b907546e8dff39c3640d7509
|
|
For one, assert.h is designed to be includeable multiple times with changing
NDEBUG settings, so it is not robust to include it early in sal/macros.h with
"correct" NDEBUG settings and potentially include it again later. For another,
there is #ifndef NDEBUG code providing functionality used exclusively within
assert calls, which must be compiled with the same NDEBUG-setting as the
relevant #include <assert.h>.
Change-Id: I7b2f9c85f8e2155051274757c64162ed5a5e9d1b
|
|
Due to the setup of gb_DEBUGLEVEL in gbuild.mk, gb_SYMBOL was always
enabled when --enable-dbgutil is set, with no way to override it.
Fix that by turning configure's ENABLE_SYMBOLS into a tri-state, where
the new "FALSE" value, set by an explicit --disable-symbols, overrides
any implicit way of enabling symbols.
But by default an --enable-dbgutil still enables gb_SYMBOL.
Change-Id: I94c609863980ed1ab9c73d7a4861c394442b531d
|
|
following logic of 608025986
Change-Id: I016b76bf350432a29e02d528814584c5dbbfff61
|
|
Change-Id: Ieb26135bb5eeee5cd472becf704e75bcbeeb8518
|
|
...had been missing. Old dmake-based build system did not add -source/-target
when using gcj (unless gcj really was Eclipse Java Compiler, in which case those
-source/-target values were tunneled in via JAVAFLAGS)---hopefully all this is
no longer necessary.
(Also removed a single use of JAVA_TARGET_FLAG that was nowhere defined.)
Change-Id: Ic3596691b622be45e151333981f8f236d11825b4
|
|
Actually I think it should be removed entirely, because dmake already
includes minor.mk directly from solenv, but I do not want to pry into it
right now...
Change-Id: I51520642f4796d722cb2131e91e9e92a82920531
|
|
Change-Id: I241be2704a069ec1f6be5861084039569673cc12
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
So drop the GVER thing and -DVCL and -DNT351.
|
|
|
|
|
|
|
|
|
|
* New SAL_INFO..., SAL_WARN... macros.
* New SAL_STREAM supersedes OSL_FORMAT.
* oustringostreaminserter.hxx moved from unotest to rtl (and always UTF-8 now).
* TODO to enable GCC __attribute__((format)) in sal/log.h (requires call-site
cleanup).
* Further functionality in tools/debug.hxx (DBG_MEMTEST, DBG_CTOR, etc.) not yet
addressed.
* Some replacements tools String -> rtl::OUString.
|
|
|
|
|
|
|
|
Also removed apparently unused UNO_JAVA_COMPPATH ProfileItem.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Can be enabled via VALGRIND_OPTS=--leak-check=yes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
