Nigel Stewart <nstewart@...> writes:
> > ...then I believe a dlsym of a GL symbol which does not exist in libMesaGL
> > can still be resolved, because of the previous global load (untested!).
> My reading of the dlsym manpage for Linux suggests that unless RTLD_DEFAULT
> is used with dlsym, only the specified library will be searched for
> symbols, along with dependencies
I think this is a moot issue given the discussion below, but I was
referring to the RTLD_GLOBAL flag for dlopen, as opposed to dlsym:
The symbols defined by this library will be made available for symbol
resolution of subsequently loaded libraries.
> > if mangled Mesa lib was linked against the system GL lib ,
> > the first dlsym would succeed even though I, as an application
> > developer, really wanted to force the mangled symbol to get loaded.
> So we should check for the mesa symbol first. We don't really
> expect to find that in a vendor-provided GL?
True. It sounds fine for my current use case.
Still, in general I think we're essentially trying to guess what the
client wants here, and I don't think we have enough information to do
that 100%. In the above case, maybe they wanted to init GLEW with the
system GL, and they have both linked into their app, so we'd do the
wrong thing. We could do a little better by checking to see if the
loaded library has a valid glX context, but then client-level bugs
where the glX init is done in the wrong library would be harder to
> > I would be more amenable to the approach if a patch adding
> > debugging support would also be accepted.
> How about a bitmask of acceptable naming conventions to bind to:
> #define GLEW_NAME_CONVENTION_NONE 0
> GLenum glewInitLibrary(const char *library, GLenum nameConvention);
I like this. Notably, it gives that 100% information I think we're
I'll provide a patch `Real Soon Now' ... I don't have any time this
weekend, but maybe the week/weekend after.