"Hi, I have a buggy piece of proprietary crap. Could you hack around it by writing a custom linker?"

I do think the correct solution is to ship a libGL for the nvidia drivers that dynamically loads the nvidia libGL when it's actually loads and not to break ld or cairo.

That said, I wouldn't object to splitting Cairo into multiple separate libs, one per lib. But that required too many public symbols that nobody wants to keep stable last I checked.

I do object though to adding lots of dlsym() calls to Cairo. Cairo is not a linker.

I think this could be a good idea anyway because libGL is a bit of a special case. Having Cairo link directly against libGL is awkward if your application is trying to use libGLESv2 because it provides most of the same symbols as libGL. For example if the application is just trying to use Cairo for the image surface backend and it links directly against libGLES it can end up accidentally using some symbols from libGL depending on the order they are linked in. Mesa starts doing weird things when this happens.

I already hit this problem when trying to use Cogl with GLES2 because Cogl also indirectly depends on Cairo. Cogl now dlopens its GL library depending on the backend to avoid this. That also enables us to choose between the GL and GLES2 backend with a runtime configuration option. Presumably Cairo could also benefit from that seeing as it has both gl and gles surface backends?

Created attachment 59169 [details] [review]
cairo-gl: Add a configure option to dlopen libGL

I went ahead and implemented a patch to make this a configure option.

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!

(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.

No, it's not. And the fact that you know that dlopen() looks at certain environment variables doesn't magically make it so either.
The fact that nobody in the real world apart from libGL ever does it could have been a very good indicator that to you that it's not the way it's designed to be used. But well, it looks at env vars, so it must be designed that way.

Now, if we wanted to fix the issues Neil has, we would split the GL using parts of cairo into a separate library and have you link against libcairo-gl.so if you wanted to use GL surfaces. In fact, that's been a long-requested feature, so that we can turn backends on (and also turn them off at will) without hurting source code or people.
But so far, nobody has figured out how to sanely do it without bleeding internal symbols so it hasn't happened. And instead people have brought down this pain again and again.

I think the portability concern isn't really a major issue because the patch makes it an opt-in configure option which defaults to off. Sure it won't work on Windows and AmigaOS but if someone tried to enable it on those platforms they would know immediately at the configure phase because the configure script errors out if you enable it when libdl wasn't found. With the configure option we can just leave it up to distros to decide if they want it.

The downside of making a separate cairo-gl library would be that it doesn't help for applications that could support either cairo-gles or cairo-gl surfaces. Those applications would have to have a compile-time option to decide which library to link to because linking to both would cause problems when both libGL and libGLES provide conflicting symbols.

For what it's worth, Cogl has been doing it this way for a while now and we haven't had any people complaining about linker issues yet.

I learnt about libepox[0] today and asked its author:

<psychon> anholt: hey, would it make sense for cairo to use libepoxy? I thought about it because of https://bugs.freedesktop.org/show_bug.cgi?id=47480
<psychon> anholt: nvidia's libGL dirties lots(?) of memory when it is loaded (at least on x86? I'm not sure), which is why I ask
<anholt> psychon: yeah, it would make a lot of sense, and cairo was one of the major targets I was thinking of when I was building it.  still need to sort out win32, though.

Disclaimer: I have zero clue about GL and I am not involved in cairo-gl. Just wanted to mention this library and perhaps someone shows up and decides to experiment with it.

[0]: https://github.com/anholt/libepoxy

Anyone know what'd need to be sorted out for Win32?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/197.