[cairo-bugs] [Bug 47480] dynamically load libGL when an application requests a GL context

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Mar 28 12:16:08 PDT 2012


--- Comment #5 from Kristian Høgsberg <krh at bitplanet.net> 2012-03-28 12:16:08 PDT ---
(In reply to comment #4)
> You are probably aware that this is going to fail at least on Apple and
> Windows.
> Did you test Solaris, BeOS and the other platforms Cairo runs on?
> Are you sure this works with LD_LIBRARY_PATH and LD_PRELOAD the way one would
> expect non-dlopen to work?
> Did you ensure that the same things happen when other parts of the application
> link against a libGL themselves? On Windows, Apple and so on? Did you
> investigate dlclose() doesn't have unintended side effects (like leaving around
> stray pointers)?
> Did you add tests for this so we don't accidentally break this later?
> If I wanted to get really harsh on you about this, I'd look through the bugs we
> closed when we still dlopen()'d libGL. Or I can just look through ld.so's
> bugzilla and link some of them for you to fix.
> I'm sure neilld.so will be awesome once you're done!

Stop talking bullshit like this.  We can just disable this for crippled
platforms, there's not need whatsoever to not fix a problem just because
AmigaOS doesn't have a certain feature.

And yes, most people don't know this but dlopen does in fact go through the
exact same logic as the regular shared linker (LD_LIBRARY_PATH, LD_PRELOAD),
because it's fricking designed to be used this way.  This is not rewriting a
linker, this is using dlopen in one of the ways it was designed to be used.

Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.

More information about the cairo-bugs mailing list