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): xmms-1.2.10-18.fc4.x86_64.rpm How reproducible: Always Steps to Reproduce: 1.Update. 2.Attempt to play music 3.
xmms was moved to extras in fc4. Reassigning there.
I confirm this - xmms says there is no output plugin within the newest update in extras! This is higly unacceptable...
If you're in an urgent need of a "fix" : - Use bmp - Downgrade, the previous version is still available from : http://download.fedora.redhat.com/pub/fedora/linux/extras/4/x86_64/ 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.
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.
I'm in libtool hell... if anyone comes up with a fix or patch for this issue, I'd be really grateful!
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.
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.
*** Bug 175675 has been marked as a duplicate of this bug. ***
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.
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.
Unfortunatly adding the dependencies doesn't fix this problem.
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 zlib-devel-1.2.2.2-5.fc4
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 aclocal automake autoconf 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.
Created attachment 122558 [details] patch allowing re auto-tooling xmms with latest autotools
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 done Resulting in the following as %build: %build %configure \ --disable-dependency-tracking \ --enable-kanji \ --enable-texthack \ --enable-ipv6 \ --with-pic for i in `find . -name Makefile`; do cat $i | sed s/-lpthread//g > $i.tmp mv $i.tmp $i done make 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. Regards, Hans
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 .
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. ...
Reassigning to Paul, as he is the current xmms maintainer :-)
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!
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)