Re: Bug#210650: libxine1: libraries not correctly linked
severity 210650 serious
That severity was not in error.
Please fix the package. Upstream is doing things upstream thinks are right,
which quite often is not the case within Debian. In this case, they are
indeed quite wrong. You *HAVE* TO LINK ANY LIBRARIES YOUR LIB _MIGHT_ NEED
AT INITIAL LINKING TIME.
On Sat, 13 Sep 2003, Marco d'Itri wrote:
> On Sep 13, Siggi Langauf <email@example.com> wrote:
> >Right now, this feature is not supported by the Debian packages, as the
> >dependancy on "xlibs" is not made optional (ie. Recommends:). This is not
Which is just damn fine. xlibs are small (well, small enough), and the
whole bang of crap one has to endure to make library linking optional and
working _right_ is NOT worth it. That's why policy dictates that if it CAN
support X11, link it against X11. Or build more than one binary package
(which for libs doesn't make much sense, it is just asking for a lot of pain
Obviously, if you're going to link against X11 because Debian's best
practice tells you to, you have to do it properly. So, you have to bring
in the xlibs in the ld invocation/gcc -o invocation, and best practive tells
you to do just that. So, you're violating best practice (as documented in
Debian policy), for no good reason, and you get a serious bug.
Now, how to fix it:
- Do the proper linking thing with the X libs and place them in Depends:
- Create a new binary package with libs that are NOT linked to X libs,
that Provides: the regular lib package, and that does not Depends: or
Recomments: the X libs. IF you deem it really needed to have libs
that don't bring in the X libs.
This is the sanest way. dlopen will cause you LOTS of grief...
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot