code base!!!
>
> It wouldn't surprise me if this feature dated from the proprietary Star
> Office days, and obviously got missed in the clean-up. (Which would
> explain why the original guy lost interest - he would have done it
> because he was told to, not because he wanted to
On 17/09/2014 00:27, nicholas ferguson wrote:
I tossed that investigation aside thinking that that route had been
poured over by LibreOffice experts; and took another look.
I didn't understand why I had to clean up this mess, with an open
source product that has been on the market, for y
On 17/09/2014 14:32, Norbert Thiebaud wrote:
On Wed, Sep 17, 2014 at 8:04 AM, nicholas ferguson
wrote:
>Thanks. There is an English language issue. Your points #1 and #2... I
>don't understand what you are referring to
It is indeed an international list.. we usually use English, but if
that
On Wed, Sep 17, 2014 at 8:04 AM, nicholas ferguson
wrote:
> Thanks. There is an English language issue. Your points #1 and #2... I
> don't understand what you are referring to
It is indeed an international list.. we usually use English, but if
that is an issue, what language would you feel more
t Thiebaud'; 'Eike Rathke'; 'libreoffice'
Subject: Re: enable-dbgutil
Hi,
On Wed, Sep 17, 2014 at 08:25:39AM -0400, nicholas ferguson wrote:
> But don't answer an email.. where the intent of the msgs is that if I
> follow your suggestions..I 'might' ge
Hi,
On Wed, Sep 17, 2014 at 08:25:39AM -0400, nicholas ferguson wrote:
> But don't answer an email.. where the intent of the msgs is that if I follow
> your suggestions..I 'might' get a build
In that case you wouldnt have an answer right now. Also note that the answer
certainly did already provid
-Original Message-
From: Jan Holesovsky [mailto:ke...@collabora.com]
Sent: Wednesday, September 17, 2014 8:40 AM
To: nicholas ferguson
Cc: 'Norbert Thiebaud'; 'Eike Rathke'; 'libreoffice'
Subject: Re: enable-dbgutil
Hi Nicholas,
I suggest we stop with t
Jan Holesovsky píše v St 17. 09. 2014 v 14:39 +0200:
> I suggest we stop with thread and start anew - is that possible?
"stop this thread" is what I meant FWIW.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.or
Hi Nicholas,
I suggest we stop with thread and start anew - is that possible?
I am sorry that you are having trouble building with --enable-dbgutil on
Windows. I used to maintain a tinderbox that had this setting on, to
avoid bitrot, but then switched that to --enable-debug (so that it can
be
Well for starters, I (Noel Grandin) am not a RedHat developer. I work
on this on my own time.
I help out on this project, including sometimes dispensing advice.
For which I do not charge a single dime.
If you need accurate rapid answers from a full-time LibreOffice
developer, then you should expec
I disagree. Answers have to be responsible.
I got one answer, and the person said, I don't have any experience with
enable-dbgutil on windows..but I advise you not to use VS 2010. That is a
responsible answer.
So tell me you don't have any experience with --enable-dbgutil on windo
On Wed, Sep 17, 2014 at 7:13 AM, nicholas ferguson
wrote:
> You obviously have never built Libreoffice under a window, using
> --enable-dbgutil. So to tell me to do extra work...on your hypothesis.
> Don't. I have tons of work then to prove our your hypothesis. And I think
>
wer me. Expert with actual experience
can tell me do a,b,c and problem solved.
As a redhat developer, you should understand that.
-Original Message-
From: Noel Grandin [mailto:noelgran...@gmail.com]
Sent: Wednesday, September 17, 2014 8:14 AM
To: nicholas ferguson
Subject: Re: enable-dbgu
You obviously have never built Libreoffice under a window, using
--enable-dbgutil. So to tell me to do extra work...on your hypothesis.
Don't. I have tons of work then to prove our your hypothesis. And I think
this rule should apply to any answers you give on Libreoffice.
I expect a R
em is solved.
>
> That is irritating to read.
That is not what I said. I told you you need to build ICU and not use
with-system and you need to rebuild everything from scratch if you
enable dbgutil.
Eike
--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG
...@redhat.com]
Sent: Wednesday, September 17, 2014 7:19 AM
To: nicholas ferguson
Cc: libreoffice@lists.freedesktop.org
Subject: Re: enable-dbgutil
Hi nicholas,
On Tuesday, 2014-09-16 09:29:01 -0400, nicholas ferguson wrote:
> I am trying to escape having to untar all of the 3rd parties and see
>
Hi nicholas,
On Tuesday, 2014-09-16 19:24:15 -0400, nicholas ferguson wrote:
> I found a working solution to an issue, that I posted today, to this list ..
> [...]
> . Nor did I get a quick answer with a solution from this list.
Do not expect answers within minutes or even not one day
Hi nicholas,
On Tuesday, 2014-09-16 09:29:01 -0400, nicholas ferguson wrote:
> I am trying to escape having to untar all of the 3rd parties and see which
> ones are missing win32 debug libs and dlls.
>
>
>
> On first pass of building Libreoffice with:
>
> --enable-db
today to this list was "what do I need to correct ? And get good
builds".
A solution I worked out today, corrected issues I was having with building
LibreOffice with "-enable-dbgutil", on a Windows platform. I verified that
correct debug lib files even for icu, were being
to this list was "what do I need to correct ? And get good builds".
A solution I worked out today, corrected issues I was having with building
LibreOffice with "-enable-dbgutil", on a Windows platform. I verified that
correct debug lib files even for icu, were being gener
I am trying to escape having to untar all of the 3rd parties and see which
ones are missing win32 debug libs and dlls.
On first pass of building Libreoffice with:
--enable-dbgutil.
build complained that
ExternalPackage_icu.mk:24 ...file icudtd53.dll does not exist in the
tarball.
So
anifest itself because I am using debug STL. The most recent of these
> is fdo#61688 "SIGABRT with debug build in VclBuilder::handleChild"
> <https://bugs.freedesktop.org/show_bug.cgi?id=61688>.
thanks for your work!
> But Julien Nabet reports
> <https://bugs.freed
ails.
(So this unfortunately means you need to do a clean build for Mac OS X
--enable-dbgutil once again.)
Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On 04/15/2013 03:34 PM, Michael Stahl wrote:
--enable-dgbutil just got better on non-mainstream platforms:
[...]
with commit a5a5104cae175f6b9a8cb4bbaccb69f0276783e3 MacOSX build define
_GLIBCXX_DEBUG (like Linux/BSD/Android builds have done for years(,
which enables debug STL.
So this unfort
c OS X 10.7.5, Xcode 4.6.1, --enable-dbgutil --with-macosx-sdk=10.7
master builds, writing numbers to std streams now suppresses all output
to those streams, so that e.g., SAL_WARN("foo","bar") only writes
"warn:foo:" to stderr (not even followed by a newline) and stops a
, which enables
>> debug STL and other things.
> [...]
>> the MSVC one is tested on MSVC 2008 only, where "make check" passes
>> successfully; it's possible that i've overlooked something in the
>> makefiles where different MSVC versions use different rules
> I wonder if we should enforce using libc++ instead of GNU libstdc++
> when using Clang on OS X and not targeting 10.6?
Nah, using libc++ leads to the mysterious errors from boost headers...
So let's forget libc++ for now, sigh. At least until we upgrade our
bundled boost.
--tml
It is known that Apple has stopped following upstream libstdc++ (just
like they have stopped following upstream GCC). Thus I assume this bug
in libstdc++ is not going to be fixed. Can it BTW be reproduced on a
Linux version that still uses libstdc++ version 4.2.1?
I wonder if there is some simple
>>writing numbers to std streams now suppresses all output to
>> those streams, so that e.g., SAL_WARN("foo","bar") only writes "warn:foo:"
The problem seems to be an old one,
http://www.runcode.us/q/c-debug-builds-broke-in-snow-leopard-x-code
Looking at the interesting parts of ostream.tcc, I sa
On 04/17/2013 08:56 AM, Tor Lillqvist wrote:
Why _GLIBCXX_DEBUG causes this problem on Mac OS X now, and how to solve it,
is still unclear to me.
I guess -D_GLIBCXX_FULLY_DYNAMIC_STRING did not do anything to improve
this? Some other magic _GLIBCXX_FOO that needs to be defined perhaps?
No, _G
ot; passes
successfully; it's possible that i've overlooked something in the
makefiles where different MSVC versions use different rules, so it needs
somebody to try it out in an --enable-dbgutil build with 2010 and 2012.
You probably did that "make check" on a build without any bun
>writing numbers to std streams now suppresses all output to
> those streams, so that e.g., SAL_WARN("foo","bar") only writes "warn:foo:"
Ah! Thanks for hunting this down, I had noticed but had not had time
to dig deeper...
> Why _GLIBCXX_DEBUG causes this problem on Mac OS X now, and how to solv
much
concerned about breakage on MacOSX; it would be helpful though if
somebody could try what happens when you run the "subsequentcheck" tests
which apparently isn't possible over SSH.
Another fallout is that, at least in
my Mac OS X 10.7.5, Xcode 4.6.1, --enable-dbgutil --
On 04/16/2013 11:13 AM, Tor Lillqvist wrote:
which to me looks like a broken libstdc++.
Hopefully was fixed by 84aea518f0dc9836350c47bff21780a5999f4968 .
Yes, build is proceeding meanwhile. Thanks.
Stephan
___
LibreOffice mailing list
LibreOffice
> which to me looks like a broken libstdc++.
Hopefully was fixed by 84aea518f0dc9836350c47bff21780a5999f4968 .
--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
much
concerned about breakage on MacOSX; it would be helpful though if
somebody could try what happens when you run the "subsequentcheck" tests
which apparently isn't possible over SSH.
Has anybody seen this working? At least my Mac OS X 10.7.5, Xcode
4.6.1, --enable-dbgutil --with-ma
Michael,
This question might be of interest to the project, but maybe it just
scratches my own itch. Please give it only as much attention as it
seems to be worth.
On Mon, 2013-04-15 at 15:34 +0200, Michael Stahl wrote of the subject
of --enable-dbgutil and debug STL:
> since we have t
build define
_GLIBCXX_DEBUG (like Linux/BSD/Android builds have done for years(,
which enables debug STL.
both of these debug modes are _NOT_ binary compatible with the non-debug
mode (which is why you have to use --enable-dbgutil to get these).
this means that if you have a --enable-dbgutil build
Hi,
Thank you for your patch! :-) It has been merged to LibreOffice.
If you are interested in details, please visit
https://gerrit.libreoffice.org/572
Approvals:
Petr Mladek: Verified; Looks good to me, approved
--
To view, visit https://gerrit.libreoffice.org/572
To unsubscribe, visit
>From Michael Stahl :
Michael Stahl has uploaded a new change for review.
Change subject: gbuild: disable symbols on --enable-dbgutil --disable-symbols
..
gbuild: disable symbols on --enable-dbgutil --disable-symbols
Due
Hi Michael,
On Mon, 2011-10-17 at 10:56 +0200, Michael Stahl wrote:
> [sorry for the late mail, but i didn't realize i had accidentally pushed
> this last week (is there an equivalent of "hg outgoing" for git?).]
Heh :-) personally I try to read the 'git diff' before committing;
and/or t
nxgcc makefiles
(guess that is all GCC using platforms except MacOSX and MinGW).
this is only active if you configure with --enable-dbgutil.
because the libstdc++ debug mode is not binary compatible with the
non-debug mode, mixing of object files with it enabled/disabled will
probably lead t
> For the internal cppunit and graphite probably need to pass
> -D_GLIBCXX_DEBUG into *their* build systems as well, no ?
On the Windows side, the internal cppunit and graphite makefiles use
dmake to build them, so there the -D_DEBUG in dbgutil mode does get
used. Not necessarily in other of the 3
On Thu, 2011-09-15 at 14:34 +0200, Michael Stahl wrote:
> of course what also needs to be prevented is linking against system
> libraries that expose STL in their interface; a quick search found me
> cppunit and graphite; the mozilla/nss stuff doesn't seem to expose STL.
This is basically the scen
On Thursday 15 of September 2011, Michael Stahl wrote:
> On 14.09.2011 20:50, Tor Lillqvist wrote:
> >> 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 m
> hmmm... but why hook this into --enable-debug, and not --enable-dbgutil?
Good question...
> AFAIK --enable-debug just enables symbols, and is otherwise intended to be
> compatible with an ordinary build.
We also have --enable-symbols ;) I don't know why we need that
separately
roblems :)
> Caolán knows more. See commit d1f6403c9ee3caf6b2e6babe5eb6b2ff62feaa9d
> and the history of the stuff it touches.
hmmm... but why hook this into --enable-debug, and not --enable-dbgutil?
AFAIK --enable-debug just enables symbols, and is otherwise intended to be
compatible with an ordinary build.
but a --ena
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
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 bui
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
> 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
p, but I'm still trying to get a working build)
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++ run
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
office/libs-core/commit/?id=ba6440349db1bd688c08369dd2b30f5dd012d339
>
> Nice! Works fine!
Yeah, the make dev-install smoketest passes with --enable-debug
--enable-dbgutil now (at least with standard configure options).
C.
___
LibreOffice mailing list
Libre
And it was tricky to try and fix draw's a11y stuff, i.e. it suffered
from calling methods in a base class ctor which triggered calling
virtual methods on the object while not complete constructed yet,
falling into the classic c++ problem where during construction that
calls the *base* class virtual
61 matches
Mail list logo
