On Wed, 4 Nov 2009, Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Wed, Nov 04, 2009 at 07:45:56PM CET:
I am not sure how one would test for this in an automated fashion
since the only effect is a performance reduction. It requires
system-dependent tools in order to watch the system calls and see
what is actually going on.
Well, as a first approximation, both the measuring and the portability
aspects can simply be ignored. Just having something that reliably
shows the issue for some setup already helps. You can even require root
rights; that may prevent most users from ever running the test (which is
good!) but will still enable developers to try it out in their sandbox.
I really hate to hijack this discussion thread since there were
already two discussion threads on this topic. Regardless, what we
should expect to see when loading a module which has no additional
dependencies is:
1) read somepath/module.la
2) stat somepath/module.so (or whatever dlname was parsed from
module.la)
3) dlopen somepath/module.so (or supporting OS calls like open, mmap,
etc.)
but instead between steps 1 & 2, we see 'stat lostsapaths/module.a'
for every path in the system's shared library search path. The reason
for this is pretty clear, since libltdl speculatively tries searching
for a preloaded module first (necessary for security), but
unfortunately, supplies the same argument to all of the available
module loaders.
Using an existing test case like lt_dlopen.at, when we are loading
"./good-plugin.la", the output of a tool like 'truss' (SVR4, Solaris,
FreeBSD) or 'strace' (Linux) should not show any attempt to access a
file called "good-plugin.a", except for possibly on AIX where a
loadable library or module might use the .a extension.
It is not normally necessary to require root access to run tools like
'truss' or 'strace' on a process that you own, but special access
might be required to run a DTrace-based tool like dtruss.
The alternative to the fancy fragile test is to simply fix the
problem, which should not be difficult since it is a simple problem.
The solution may be to add a flag which indicates that the desired
load should be static linkage so that only the preloader processes the
request.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
