Bug 175493 - Xmms no longer plays anything...
Summary: Xmms no longer plays anything...
Alias: None
Product: Fedora
Classification: Fedora
Component: xmms   
(Show other bugs)
Version: 7
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Paul F. Johnson
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
: 175675 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-12-11 22:15 UTC by James Wilkinson
Modified: 2007-11-30 22:11 UTC (History)
9 users (show)

Fixed In Version: 1.2.10-19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-14 17:07:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch allowing re auto-tooling xmms with latest autotools (4.89 KB, patch)
2005-12-23 09:40 UTC, Hans de Goede
no flags Details | Diff

Description James Wilkinson 2005-12-11 22:15:37 UTC
Description of problem:
After update to xmms-1.2.10-18.fc4.x86_64.rpm, attempting to play music comes up
with "No output plugins have been selected". When you attempt to choose an
output plugin, no options are available.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
2.Attempt to play music

Comment 1 John (J5) Palmieri 2005-12-12 04:07:46 UTC
xmms was moved to extras in fc4.  Reassigning there.

Comment 2 Adam Pribyl 2005-12-12 17:43:19 UTC
I confirm this - xmms says there is no output plugin within the newest update in
extras! This is higly unacceptable...

Comment 3 Matthias Saou 2005-12-12 17:58:10 UTC
If you're in an urgent need of a "fix" :
- Use bmp
- Downgrade, the previous version is still available from :

Now, about the problem... for some reason, all the plugins only got installed
as static libraries (.a) instead of shared libraries (.so)! This seems to
have happened only on x86_64, and the build log is no longer available to try
and see what exactly went wrong.

Comment 4 Matthias Saou 2005-12-12 18:18:14 UTC
On my own build machine, I am able to reproduce the problem with mock but not
with mach. This is almost certainly due to some difference in the build
environment (and Extra uses mock, so that figures).

I'm currently trying to find the cause, or at least a workaround.

Comment 5 Matthias Saou 2005-12-12 19:07:54 UTC
I'm in libtool hell... if anyone comes up with a fix or patch for this issue,
I'd be really grateful!

Comment 6 Jonathan Ryshpan 2005-12-13 04:26:45 UTC
I have rebuild from source (xmms-1.2.10-18.fc4.src.rpm) on my home machine: FC4,
latest revisions, running on an x86-64 processor.  The resulting binary RPM
appears to install and run fine.  This latest version seems to have also removed
an annoying buzz that I've sometimes had.

Comment 7 Matthias Saou 2005-12-13 09:34:47 UTC
Yes, as I wrote, it also rebuilds fine for me using mach, but not using mock,
so there is some difference in the build root that makes this happen.
Comparing both build logs, there was only the configure bison check that
differed, so it's not even in the set of relevant installed packages, but
almost certainly in some lower level libraries.

Comment 8 John (J5) Palmieri 2005-12-13 21:53:44 UTC
*** Bug 175675 has been marked as a duplicate of this bug. ***

Comment 9 Matthias Saou 2005-12-20 14:04:51 UTC
Thinking a little more, this might actually be miltilib related, as if some
package is explicitely listed in the mock base packages, yum will install all
available archs, thus i386 and x86_64 in this case. So if that package isn't
explicitely listed in mach, and pulled in as a dependency, that might explain
the difference in behavior.

I'll check this in detail soon.

Comment 10 Hans de Goede 2005-12-22 16:26:33 UTC
As promised on the mailinglist I'm examining this. Currently I've found out that
xmms.spec misses a few needed BuildRequires for the devel branch (all xorg
modular related). Here is a list of missing BuildReqs:
BuildRequires: libSM-devel
BuildRequires: libXxf86vm-devel
BuildRequires: mesa-libGL-devel  
BuildRequires: zlib-devel

I found these by doing a diff -ur on a local build dir and a mockbuild build dir.

I'm currently trying a mockbuild to see if this fixes this problem, which would
be strange, but libtool is strange. I'll get back to you once the mockbuild is
done, which may take a while since my internet connection is rather slow.

Comment 11 Hans de Goede 2005-12-22 17:19:51 UTC
Unfortunatly adding the dependencies doesn't fix this problem.

Comment 12 Jonathan Ryshpan 2005-12-22 18:34:47 UTC
I seem to have got a good build without most of these packages.  This is from
the machine that I did the build on referred to in #6.

$ rpm -q libSM-devel libXxf86vm-devel mesa-libGL-devel zlib-devel
package libSM-devel is not installed
package libXxf86vm-devel is not installed
package mesa-libGL-devel is not installed

Comment 13 Hans de Goede 2005-12-23 09:38:38 UTC
In reply to comment #12,
Yeah as I already suspected and reported in comment #11 not having these
BuildReq's is not the cause of the problem, they still should be added though
since xmms can use them and thus without them a less functional xmms gets build.

I've tried fixing the problem by re-libtoolizing xmms with "libtoolize --copy
--force", but after that xmms doesn't compile any more. So I've tried completly
reautotooling it with:
libtoolize --copy --force

In order to make this possible I've written a small patch, unfortunatly although
the entire reautotooling works without any warnings, the compile still fails
with the same error as after just the "libtoolize --copy --force" .

I'll attach the patch just in case it is needed in the future ( I think
reautotooling without updating libtool might work).

Currently I'm working on an "ugly hack (TM)" which will hopefully work.

Comment 14 Hans de Goede 2005-12-23 09:40:29 UTC
Created attachment 122558 [details]
patch allowing re auto-tooling xmms with latest autotools

Comment 15 Hans de Goede 2005-12-23 10:25:17 UTC
Well, the "ugly hack (TM)" patch is finished. I dunno why adding -lpthread makes
libtool barf, but I do now that -lpthread is not nescesarry since pthread is a
default part of the libc nowadays. So I've just removed all -lpthread references
from the makefile.

If you add the following line between configure and make in %build:
for i in `find . -name Makefile`; do
  cat $i | sed s/-lpthread//g > $i.tmp
  mv $i.tmp $i

Resulting in the following as %build:
%configure \
  --disable-dependency-tracking \
  --enable-kanji \
  --enable-texthack \
  --enable-ipv6 \
for i in `find . -name Makefile`; do
  cat $i | sed s/-lpthread//g > $i.tmp
  mv $i.tmp $i

gcc -fPIC $RPM_OPT_FLAGS -shared -Wl,-soname -Wl,librh_mp3.so -o librh_mp3.so \
     %{SOURCE5} -I. `gtk-config --cflags gtk`

Then it mockbuilds correct with .so plugins and the result runs fine too.



Comment 16 Hans de Goede 2005-12-28 14:45:37 UTC
On request of Matthias I've pushed through a build on both FC-4 and devel with
my hack^H^H^H^Hfix included, so this should be fixed in tomorrows FE packages
push. Its fixed in 1.2.10-19.fc4 resp 1.2.10-19.fc5 .

Comment 17 Axel Thimm 2007-06-21 09:20:13 UTC
The fix with removing -lpthreads on the fly is not stable and the package only
builds by happenstance, e.g. if libtool detects a i386 glibc which seems to be
the  default in currently used buildroots.

So currently the seding out of -lpthreads from Makefiles only pretend to remove
-lpthread as *-config and friends easily reintroduce it:

+ find . -name Makefile
+ xargs perl -i -e s/-lpthread//g
+ make
/bin/sh ./libtool --mode=link gcc  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
-Wall -Wpointer-arith   -o libxmms.la -rpath /usr/lib64
 -export-dynamic -version-info 4:1:3 configfile.lo xmmsctrl.lo dirbrowser.lo
util.lo formatter.lo titlestring.lo xentry.lo xconvert.lo -L/usr/lib64
-L/usr/lib64 -lgtk -lgdk -rdynamic -lgmodule -lgthread -lglib 
-lpthread -ldl -lXi -lXext -lX11 -lm  
rm -fr .libs/libxmms.la .libs/libxmms.* .libs/libxmms.*

*** Warning: linker path does not have real file for library -lpthread.

Comment 18 Matthias Saou 2007-06-22 14:36:21 UTC
Reassigning to Paul, as he is the current xmms maintainer :-)

Comment 19 Paul F. Johnson 2007-06-25 21:52:30 UTC
Have you tried the version either in anything above or in FC6 (the current
lowest supported version of core?)

The versions in F7 and rawhide both work - I'm using them here!

Comment 20 Axel Thimm 2007-06-26 12:55:56 UTC
Have you tried rebuilding them? Or tried to build mplayer against xmms?

(and the version in rawhide is the one from F7, so at this point in time the
runtime behaviour should really be identical)

Anyway I found the fix that also makes filtering away lpthreads unnecessary: You
need to replace /usr/lib with /usr/lib64 everywhere and everything builds
properly including mplayer.

From my POV I don't need this bug anymore. You may want to keep a reminder for
it when you will need to rebuild xmms for whatever reason (e.g. POST or DEFERRED)

Note You need to log in before you can comment on or make changes to this bug.