My thanks go to Stephan Bergmann, who also responded to my question.
On Mon, 2010-03-29 at 15:00 +0200, Eike Rathke wrote:
> Hi Terrence,
>
> On Friday, 2010-03-26 13:42:28 -0400, Terrence Enger wrote:
>
> > However, I have not found what library holds the object code for
> > operators_new_delete.cxx.
>
> Let's see.. operators_new_delete.cxx is in sal/cpprt/, the
> sal/cpprt/makefile.mk says TARGET=salcpprt, then for "$(OS)" !=
> "SOLARIS" we have LIB1ARCHIV containing $(TARGET), so the resulting
> archive is libsalcpprt.a, which then per solenv/inc/$INPATH.mk and
> solenv/inc/tg_app.mk is linked to applications.
I had found libsalcpprt.a using nm and grep. Silly me, I did not look
farther than lib/.
>
> > I tried changing the source in operators_new_delete.cxx, but a rebuild
> > did not reflect changes. I presume ...
> >
> > (a) Something in the build process does not recognize a dependency
> > that it should. Does this sound plausible? Should something be
> > fixed? Alas, I do not know enough even to think about the
> > question.
>
> Linkage dependencies are not tracked, a long outstanding deficiency..
> a (quite) safe bet is to
> rm */$INPATH/{lib,bin}/*
Where INPATH is unxlngi6 for me, right?
I dunno how I screwed up, but I ended up unable to build. I now have
started over from the tarfiles and will carry on from there.
> and build all. Given that apparently only applications are affected
> here, a rm */$INPATH/bin/* might do as well.
>
> > (b) A full build will incorporate my changes. It should not be long
> > until _m76.
> >
> > The assertion failures are so distracting that I am considering
> > removing the source line altogether from _m76 when it comes out.
>
> Strong veto. This is the only safe mechanism to detect these errors,
> which are real errors as the alloc/free procedures differ between array
> and non-array allocations.
>
> > After all, it seems that most people do not even try to use a
> > non-production build.
>
> IIRC the assertion is thrown only in a unxlng* non-product build, most
> developers using non-product builds unfortunately do this on Windows,
> developers building their own on Linux unfortunately don't use
> non-products because it has to be explicitly enabled during configure
> (to be changed?).
A website page about building OOo says that non-product builds are
used almost exclusively within Sun. For a long time, I incorrectly
took that to be a warning that they are hard to accomplish rather than
merely a description of a regrettable state of affairs. Perhaps we do
not want to encourage a non-product build for a newcomer's very first
attempt, but I could have been finding these assertions long ago.
Would a change to the website be in order?
( Heh, I had a reason for trying a non-product build. Maybe I will
eventually get around to dealing with that. Maybe. )
> So the set of developers actually using Linux
> non-products is quite small.
>
> > If I had hope of being able to track down more causes, that would
> > change my attitude.
>
> Please change your attitude nevertheless ;-)
Consider it changed. So long as I am making a positive contribution.
( I think, though, that I am giving up on trying to use a non-product
build when I actually want to get work done <grin />. )
>
> It seems you have hit an area that introduced these errors quite
> recently. I usually work with non-products and didn't encounter any up
> to m73 or so, working mainly within in Calc though.
I wandered into Base. On a hug-a-bug day over there, issue 94543
<http://www.openoffice.org/issues/show_bug.cgi?id=94543> caught my
attention, and the rest follows from that. Some of it follows at
quite some distance.
Part of that following at a distance included figuring out how to use
detached debugging symbols to get a more informative backtrace the
first time an assertion comes up. I start to feel conspicuous about
the number of issues I have been submitting.
Thank you for the help.
Terry.
>
> Eike
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
