I wrote:
> I had to in them do an explicit
> #define _HAS_ITERATOR_DEBUGGING 0
> I wonder if that affects the layout of some structs/classes? In that
> case of course compiling just some source files with this would cause
> horrible run-time crashes...
Hmm, the comment in
http://msdn.microsoft.c
> Actually change of the default value of _ITERATOR_DEBUG_LEVEL (which, as
> far as I understand it, is the MSVC's equivalent of _GLIBCXX_DEBUG)
Hmm, isn't it just _DEBUG ? Anyway, now that you say that, I come to
think that in order to make a few files compile with -D_DEBUG at all,
I had to in th
On Wed, Sep 14, 2011 at 09:50:13PM +0300, Tor Lillqvist wrote:
> (I must say I am a bit disappointed at the GNU C++ library here: this
> thing that you can't mix code compiled with and without that define,
> and don't even get any linkage error if you do anyway, doesn't sound
> very elegant; in fac
> but currently LO doesn't seem to use it (couldn't find -D_GLIBCXX_DEBUG); why
> is that?
We tried, but we ran into so many problems when code compiled with
that without that were mixed (accidentally/unintentionally) that we
gave up.
Caolán knows more. See commit d1f6403c9ee3caf6b2e6babe5eb6b2f
On 14.09.2011 17:21, Fridrich Strba wrote:
> Hello, Michael,
>
> On 14/09/11 16:57, Michael Stahl wrote:
>> in OOo, --enable-dbgutil enables DBG_ASSERT and the STL debug mode,
>> linking against stlport_debug (on platforms where STLport is used).
>
> Just for the record, nothing in LO links again
Hello, Michael,
On 14/09/11 16:57, Michael Stahl wrote:
> in OOo, --enable-dbgutil enables DBG_ASSERT and the STL debug mode,
> linking against stlport_debug (on platforms where STLport is used).
Just for the record, nothing in LO links against stlport anymore. If
stlport is built and distributed
Ah, my mistake, I thought you were just running the generated binary from the
command line.
Odd, because I would have expected the Visual Studio Debugger to stop the
program on any unhandled exception, or if it
hit an assert.
-- Noel Grandin
Tor Lillqvist wrote:
>> I suspect you'll get much f
> if the person who introduced this regression had used --enable-dbgutil
> then they would have found it themselves.
I am hoping that the revert Fridrich just pushed will help in the
dbgutil build too, will see soon (or tomorrow, depending on how much
needs to be recompiled now after a pull...)
I
> I suspect you'll get much further if you try to run a debug build under the
> Visual Studio debugger.
Umm, what do you think I am doing then? Of course that is what I do.
(gdb can't be used to debug MSVC-compiled code anyway, not that I see
why one would want to.)
--tml
On 14.09.2011 16:39, Tor Lillqvist wrote:
> Over the past month or so I have hacked, now and then, on making it
> possible to build master on Windows (i.e. with MSVC) with
> --enable-dbgutil, where --enable-dbgutil now means that the debugging
> C/C++ runtime is used (and _DEBUG is defined when com
Hi
I suspect you'll get much further if you try to run a debug build under the
Visual Studio debugger.
The VS Debugger and the runtime debug library are designed to work together, so
you'll probably get a much better idea
of what is going wrong.
-- Noel Grandin
(Would love to help, but I'm stil
Over the past month or so I have hacked, now and then, on making it
possible to build master on Windows (i.e. with MSVC) with
--enable-dbgutil, where --enable-dbgutil now means that the debugging
C/C++ runtime is used (and _DEBUG is defined when compiling, which
means that for much of the MSVC C++
12 matches
Mail list logo
