>>> Installing (2 of 2) media-sound/mpg123-1.7.3 * checking 26 files for package collisions * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / <filename>` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at http://bugs.gentoo.org unless you report exactly which * two packages install the same file(s). Once again, please do NOT file * a bug report unless you have completely understood the above message. * * package media-sound/mpg123-1.7.3 NOT merged * * Detected file collision(s): * * /opt/gentoo/usr/lib32/libltdl.so.8.0 * /opt/gentoo/usr/lib32/libltdl.la * /opt/gentoo/usr/lib32/libltdl.a * /opt/gentoo/usr/include/ltdl.h * /opt/gentoo/usr/include/libltdl/lt_system.h * /opt/gentoo/usr/include/libltdl/lt_error.h * /opt/gentoo/usr/include/libltdl/lt_dlloader.h * /opt/gentoo/usr/lib32/libltdl.so.8 * /opt/gentoo/usr/lib32/libltdl.so * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * sys-devel/libtool-2.2.6a-r00.1 * /opt/gentoo/usr/include/libltdl/lt_dlloader.h * /opt/gentoo/usr/include/libltdl/lt_error.h * /opt/gentoo/usr/include/libltdl/lt_system.h * /opt/gentoo/usr/include/ltdl.h * /opt/gentoo/usr/lib32/libltdl.a * /opt/gentoo/usr/lib32/libltdl.la * /opt/gentoo/usr/lib32/libltdl.so * /opt/gentoo/usr/lib32/libltdl.so.8 * /opt/gentoo/usr/lib32/libltdl.so.8.0 * * Package 'media-sound/mpg123-1.7.3' NOT merged due to file collisions. * If necessary, refer to your elog messages for the whole content of the * above message.
This patch to the ebuild resolves the problem - but why is it needed? --- mpg123-1.7.3.ebuild +++ mpg123-1.7.3.ebuild @@ -65,4 +65,6 @@ src_configure() { src_install() { emake DESTDIR="${D}" install || die "emake install failed" dodoc AUTHORS ChangeLog NEWS* README + + find "${D}" -name \*ltdl\* -exec rm -r {} \; }
*** Bug 276120 has been marked as a duplicate of this bug. ***
I'm not sure which system was used in bug 276120, but this is happening with libtool 1.5.x and 2.x on different system(s) by looks of it. Adding Thomas (upstream) to CC so he can take a look, I can only assume (because I can't reproduce) this is because something is missing in configure.{ac,in} stop the libtool getting copied over to the source directory and then installed in users system.. Also, users, please try 1.8.1
Thomas, this is completely off-topic but just a note: -faltivec doesn't work with GCC on Linux so I think you shouldn't add that to CFLAGS in configure.{ac,in} if Linux and/or GCC is detected (It's a Darwin specific CC flag IIRC). It will only abort with unrecognized option.
(In reply to comment #4) > Thomas, this is completely off-topic but just a note: -faltivec doesn't work > with GCC on Linux so I think you shouldn't add that to CFLAGS in > configure.{ac,in} if Linux and/or GCC is detected (It's a Darwin specific CC > flag IIRC). It will only abort with unrecognized option. yes, but obviously it's a not so good thing to use on Intel Macs, so preferably don't set it, user's CFLAGS will do so automagically on e.g. -mtune=G5. Since this also happens on Linux, I wonder if this bug is correctly assigned. Leaving as is, for now.
This is upstream speaking (thanks for CC)... 1. The libtool cruft is irrelevant with 1.8.1, I removed the local libltdl copy, now always relying on a libltdl in the system if one wants modules. I got sick of such random issues like the one we got here. So, update and be happy;-) 2. About altivec... that is actually specific to MacOS and the configure script only selects this decoder on appropriate systems: *-apple-darwin*) AC_MSG_CHECKING([if CPU type supports AltiVec]) case `machine` in ppc7400 | ppc7450 | ppc970) AC_MSG_RESULT([yes]) cpu_type="altivec" ;; *) AC_MSG_RESULT([no]) cpu_type="generic_fpu" ;; esac ;; OK, this check may not be perfect (hardcoding stuff), but at least it should not fire on Linux/PPC. Also, gcc wouldn't stop at -faltivec alone, it would stop also at the missing library support for the vector routines used in the AltiVec code;-) (PS: sucks having to create an account for commenting here after having written all the stuff into the readily available comment form already)
Confirm that mpg123-1.8.1 installs successfully on IRIX without changes.
(In reply to comment #6) > OK, this check may not be perfect (hardcoding stuff), but at least it should > not fire on Linux/PPC. Also, gcc wouldn't stop at -faltivec alone, it would > stop also at the missing library support for the vector routines used in the > AltiVec code;-) We pass --with-cpu=altivec on PPC and PPC64 if so called USE flag "altivec" is enabled, and most PowerPC users have. Then we _sed_ simply: sed -i -e 's:-faltivec::g' configure And it builds fine. Are you trying to say the altivec code doesn't work on Linux? We have been doing this for an year without issues, but I'd like to drop this hack from our ebuild (the Gentoo installation script)
Please could we use an alternative character as the separator in sed scripts? IRIX *FLAGS include ':' characters, which then breaks builds if these sed statements are ever executed. How about the pipe character - that shouldn't ever occur within the value assigned to these variables...
Hm, that is a bit embarassing, but indeed I wasn't aware of the altivec library being available under linux. The Apple-using people in the mpg123 Team who added that code were mostly talking about MacOS and I did not have a PPC linux system to test on. Also, since our configure obviously doesn't do this out of the box, they obviously only ran it on MacOS. Interesting news;-) Seems like we should modify the configure script to default to altivec-enabled build when on ppc linux, barring the extra compiler flag. No big deal, then. I just need to be aware of that (the project lead doesn't have every possible system at hand to test...).
(In reply to comment #10) > Hm, that is a bit embarassing, but indeed I wasn't aware of the altivec library > being available under linux. No worries. Now you do. :-) Anyway, I've opened a second bug requesting 1.8.1 into stable, so there's nothing left in this bug to do. Users can follow up on 278597.
