On 03/26/10 18:42, Terrence Enger wrote:
However, I have not found what library holds the object code for operators_new_delete.cxx. So it is hard to set a breakpoint to see what heap address is causing the assertion. (When a system library is calling delete or delete[], it is hard to work back to the call. When it is a proprietary driver doing the call, it is again hard; but now "hard" has an entirely different meaning <grin />.)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. (b) A full build will incorporate my changes. It should not be long until _m76.
sal/cpprt/operators_new_delete.cxx compiles to an archive libsalcpprt.a, delivered from sal to solver (cd sal && build && deliver). That archive in turn is linked into executables via solenv/inc/_tg_app.mk (variables APPnLIBSALCPPRT). However, the dependency between the archive and the resulting executables is not tracked by the OOo build system. The easiest way to get a new soffice.bin executable that contains the changes to the archive is to do
cd desktop && rm -r $INPATH && build && deliver The solver bin directory will then contain a new soffice.bin. -Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
