[vlc-devel] [patch] Alter symbol-globalising dlopen(RTLD_NOLOAD) call to succeed

[Rémi Denis-Courmont]

On Fri, 13 Feb 2009 13:07:56 +0100 (CET), jpd at m2x.nl wrote:
> On Fri, February 13, 2009 12:24 pm, Rémi Denis-Courmont wrote:
>> AGAIN, the symbols can come from something ELSE than libvlccore.so.
>> That's the whole point. If we _are_ a libvlccore(.a) linked into another
>> object, we don't want to go and override ourselves with whatever
>> _other_ image of libvlccore(.so) happens to be in our process space.
>>
>> What we want to expose it ourselves (whatever that means), not
>> /usr/lib/libvlccore.so.
> 
> I do not think that dlsym is the correct way to infer that case.

Well, it is a hack. And so is the following dlopen(). But I am not aware of
any way to do what we want/need with libdl other than that, or linking the
plugins against libvlccore. The later, among other things, implies getting
rid of revision.c, which I has been forced onto VLC by M2X in the first
place.

> In fact and despite my limited knowledge of ld.so, I am reasonably
> sure it is an incorrect way. It seems to me to be something for ld.so
> to do using weak symbols, and if not perhaps using the preprocessor.

If you know a better solution, you're welcome to implement it.

> But even so, all I'm looking for is to solve a problem which appears to
> be solved by removing the dlsym call, and if you object to removing it,
> please explain how RTLD_GLOBAL can be set on the libvlccore{.a,.so}
> symbols needed by later modules, because without that flag the mozilla
> plugin certainly does not work.

> Personally, I do not share your need to construe asking a question about
> the latter on irc as pushing for the thing. The former you will have to
> take up with Saman and the other companies that would like it, I'm sure
> they will be looking forward to your thoughtful arguments.

revision.c was added (in a disruptive way) by M2X a long time ago, removed
by me, re-added in complete disregard of my technical objections by M2X,
then removed again by me, and finally fixed by not linking plugins against
libvlccore.

I have no problems linking the plugins via libvlccore again, but that
implies:
- getting rid of revision.c - for real this time, and
- putting adequate safeguards against statically linked libvlccore, which
have been missing this far.


>From the your complaints and those of the bindings maintainers, I infer
that we should revert to that model. But I will only do that if I have M2X
word that they won't bring revision.c back in any form. Ever. I have waste
too many hours on this annoyance.

-- 
Rémi Denis-Courmont