On Tue, Jan 02, 2001 at 03:24:29AM -0500, James Abbatiello wrote:
> Andreas Mohr wrote:
> > You don't really want to do that.
> > That way you have to do that check *every* time you call that function.
> > Much better to do it once upon startup (somewhere in that file preferrably),
> > IMHO.
>
> Yes, you'd have to do the check every time. But one simple comparision
> would seem to be insignificant compared to the time the actual dlopen()
> would take to load the library. Not to mention the 4 calls to dlerror()
> that we've already added to compensate for glibc. Even those alone
> should greatly outweigh the time this check takes. And I'm working
> under the assumption that dlopen() isn't a particularly time-critical
> function. Does it work though?
Hmm, maybe you're right.
Sorry, I couldn't test whether it works.
I had to reboot my notebook (init frozen due to init suspend-to-disk
incompatibility), and after that my X wouldn't come up again
(can't resolve symbols in r128_drv.o).
Everything ok with symbols, though.
I didn't have a single clue about that problem... until my thoughts went
back to libc6 2.2-8.
Downgraded to 2.2-6 -> WORKED.
Conclusion: 2.2-8 is bull*SHIT*.
And no, I will not go back to 2.2-8 now (you don't just change your libc
lightly in a non-distribution way).
But on the other hand I'm pretty damn sure that your workaround would work.
The usefulness of that fix remains to be questioned, though,
given the fact that I couldn't even restart X any more ;-)
Maybe we want to abandon that fix then...
This version is utter crap anyway.
Hmm, or maybe just add it with a comment, and when everybody is using
glibc 3.3.2, then we'll just remove that 2.x crap again.
*sigh* I guess I vote for including that workaround.
Andreas Mohr
