Re: Bug#72140: Setting up libraries too slow
William Lee Irwin III wrote:
>
> This thread has already gone on too long, but I'll chip in my two cents'
> worth. Basically, it's a minor, but nice feature. Now, for the reactions...
>
So some guru has to come in and say Period? You have written about
all the auxiliary issues but missed on the subject of the thread. This
is about a bug that I've filed about the slowness of a maintenance task.
I don't care who runs it or when it is run. I just don't like slow
and badly written things.
Could you please tell me where exactly the bottleneck is because it's
been suggested that it might not be in ldconfig. You should be able
to answer that since you are so familiar with linkers.
> This is largely a matter of taste. I'd tend to fall on the side of
> integrating the cache updates into the dynamic linker.
Agreed. Lazy evaluation rather than redundant updates. If that's what
you mean here?
> I don't bother
> watching any of the long-running junk run. Linux multitasks, and
> so do I.
Imagine that you're doing a routine fresh Debian installation, what do you
multitask then?
> Various schemes have been devised for integrating
> programming language support into linkers, from link-time code
> generation to linker support for nonlocal variable access, link-time
> typechecking, and link-time class descriptor allocation. Java seems
> to do a few of these in its linker/loader whatever. I don't believe
> there are many, if any standards on this issue, but to my eyes, cache
> invalidation in the dynamic linker seems like a very minor feature.
The only thing I'm looking forward to in this area would be a C++
implementation that does link-time code gen. Then generic libraries could really
be libraries and _not just headers_ Do you know of a working example
in this vein?
Thanks,
--
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo
Reply to: