Hi Francois,
On Mon, 2011-05-09 at 08:25 +0200, Francois Tigeot wrote:
The cleanup is great of course. It is well worth checking, before each
piece of fixing inside tools/ itself, whether we can save more time by
re-writing the (sometimes rather few) call-sites, to use sal/ classes
instead (?) :-)
It would be best; many methods were already unused and DirEntry screams to
be removed from the tree. Howewer, since I lack knowledge of the different
APIs, I'm only doing this sort of incremental cleaning for now.
Ah - so './g grep DirEntry' is your friend I suspect :-) If you remove
a whole class, and the code still compiles - then we can be fairly sure
it wasn't used[1]. If a method is not virtual [ this can be hard to
tell, the 'virtual' keyword is not mandatory - you have to look at the
parent classes to see ], then it is also easy to remove. If you have a
compile tree, you can grep in all the libraries for that symbol so there
are several ways to do that, here is one way:
objdump -T solver/300/unxlngi6.pro/lib/libtlli.so | c++filt | nl | less
.. find your symbol eg. ...
393 000278de g DF .text 000000bb Base DirEntry::GetBase(char) const
Now - this is really a mangled symbol - which we can grep for easily,
but the c++filt has made it human read-able; if we remove the
c++filt, we see that line 393 is:
393 000278de g DF .text 000000bb Base _ZNK8DirEntry7GetBaseEc
which (by inspection after a while) - you can see is the DirEntry
method of that name.
So - then we can just grep the entire install for this symbol:
$ grep -R _ZNK8DirEntry7GetBaseEc *
Binary file basis3.4/program/libtlli.so matches
Binary file basis3.4/program/testtool.bin matches
Binary file basis-link/program/libtlli.so matches
Binary file basis-link/program/testtool.bin matches
And we see that only the testtool (old code) and tools uses this method
- so, perhaps by killing it in testtool we can bin that method. Of
course - if we want to look for all instances of this class:
$ grep -R _ZNK8DirEntry *
we get more hits - seven or so - which we can chase I guess.
Anyhow - hopefully that is helpful for someone :-)
Thanks !
Michael.
[1] - assuming it exports no extern "C" { component_* (); } type methods
which are hooked by dlsym when the module is dlopened.
--
michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.