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: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org