Re: KDE 3.1.5 Status Update - 20040119
> kdeaddons
> ---------
> alpha - failed - libxine missing(?)
> hppa - failed - libxine missing(?)
> mips - failed - libxine missing(?)
> mipsel - failed - libxine missing(?)
> powerpc - failed - libxine missing(?)
> s390 - failed - libxine missing(?)
> sparc - failed - libxine missing(?)
>
> not sure what is wrong here it built on several archs but failed the
> same way on the rest...
My first guess is that noatun might be built against libxine on those
particular archs, which means that libtool looks for libxine.la when it
builds the noatun plugins. In the particular plugin where kdeaddons is
failing, the Makefile.am only has -lnoatun in addition to the usual KDE
libraries. A quick grep in fact suggests that there's nothing at all in
kdeaddons that could be dragging in libxine directly.
An extension of this guess is that noatun might build in xine support if
it happens to finds libxine on the system, but libxine-dev is not
explicitly in the kdemultimedia build-depends. This would account for
the fact that some archs have it and some don't, and the fact that it's
not listed in the depends for kdemultimedia-dev.
If this is true, presumably either (i) libxine-dev must be explicitly added
to kdemultimedia build-depends and kdemultimedia-dev depends so that
noatun always has xine support, or (ii) xine support must be explicitly
disabled in noatun (hopefully through a configure flag, otherwise
through a build-conflicts with libxine-dev) so that noatun never has
xine support and no unexpected build-depends creep through to other
packages.
Of course this is all pure speculation - I haven't actually had a chance
to downloaded the kdemultimedia sources and take a look.
> quanta
> ------
> m68k - failed - due to automake 1.4, wtf?
This has been a long-standing problem hasn't it - I'll do a new upload
with a build-conflicts on automake1.4.
Ben.
Reply to: