Re: Bug#210650: libxine1: libraries not correctly linked
On Sat, Sep 13, 2003 at 12:11:17PM +0200, Siggi Langauf wrote:
> On Sat, 13 Sep 2003, Marco d'Itri wrote:
> > On Sep 13, Siggi Langauf <firstname.lastname@example.org> wrote:
> > >However, that was done intentionally (upstream): all X related functions
> > >are _only_ called if xlibs are actually installed, which is necessary in
> > >order to support setups without X11 (as used by fbxine and aaxine, for
> > >example).
> > Then it should use dlopen. With 13 symbols this is hardly difficult.
> > I do not think this bug should be downgraded, but I'm Cc'ing
> > debian-devel to read the opinions of other developers.
> IIRC, dlopen() is not a good idea, either: The symbols are needed exactly
> in the case that the front end application (which links against libxine)
> is linked against the X libs. dlopen()ing would map the libs a second
> time, which AFAICT breaks things like XLock() which must be called on the
> same instance of the X client lib, or else bad races may occur...
> Please CC me (or the BTS) on any answers, as I'm not on -devel!
Or, of course, you could solve this in another way. You want to call
the X functions iff something else has caused them to be linked in,
If you declare them as weak external symbols, then you can test their
value against NULL and call them if non-NULL. Like so:
extern int XSomethingOrOther (int) __attribute__((weak));
That will make prelink stop complaining; they'll become conflicts which
have to be fixed up at runtime, but that's life.
MontaVista Software Debian GNU/Linux Developer