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

[Rémi Denis-Courmont]

    Hello,

On Fri, 13 Feb 2009 14:45:10 +0100 (CET), jpd at m2x.nl wrote:
> I must confess that I have no idea why linking plugins against libvlccore
> or the existence of revision.c is in any way or form a factor in calling
> dlsym on something else entirely.

revision.c, by essence, needs to be regenerated pretty much all the time.
In theory, it depends on every single file in the source repository. In
practice, the ony realistic way to implement that, is  to be regenerate the
file every time.

That has the (expected) consequence that revision.c is recompiled every
time, and then that libvlccore is relinked everytime. That typically takes
a few seconds. But then, the way make works, we end up relinking any target
that links against libvlccore, and recursively. Currently, that affects
libvlc, vlc, and the web plugins, which is not very nice.

If we link the plugins against libvlccore, then we need to relink almost
every single target in the tree. That is entirely unacceptable for
development. Lest someone "fixing" make, we have an exclusive choice
between revision.c and linking plugins against libvlccore, as we arguably
should. I have already stated several times that I would prefer removing
revision.c, and so would a bunch of other developpers. The only one that I
know is in the "camp" for not linking against libvlccore is Pierre d'H,
because that anyway speeds up the build regardless of revision.c.

*But*, inspite of my objections, M2X has on _several_ occasions brought
revision.c back into the build.

> I have to focus on the webbrowser plugins for the moment, not on
> loader trickery for what appear to be wilfully nonstandard cases.

That's typical M2X behavior. Focus on short term business-focused hacks,
and put the fixing and long-term maintainance burden on volunteer
developpers. And then blame me as I try to fix their bugs. Frankly, I have
really had it with your employer.

-- 
Rémi Denis-Courmont