With new USE-flag "mp3" wine cannot be configured, ./configure throw this error: checking for mpg123_feed in -lmpg123... no configure: error: libmpg123 development files not found (or too old), mp3 codec won't be supported. This is an error since --with-mpg123 was requested. I tried with media-sound/mpg123 1.8.1 and 1.9.0, in both case same error. Reproducible: Always Steps to Reproduce: 1. USE="mp3" emerge -av =wine-1.1.29 2. Get error
Created attachment 203292 [details] wine build log
Created attachment 203294 [details] emerge --info
not a bug in wine. you have to provide the 32bit mpg123 libraries yourself, or dont USE=mp3.
Same problem here :-( Shouldn´t the mp3 useflag for wine on AMD64 then not be masked?
Same problem, please fix ebuild for amd64 arch.
Isn't it that package management systems exist just so we don't have to provide libraries ourselves? ...
(In reply to comment #3) > not a bug in wine. you have to provide the 32bit mpg123 libraries yourself, or > dont USE=mp3. > But if I run ./configure --with-mpg123 manually everything OK. So, if there arch bug, maybe better add mp3 to package.use.mask?
(In reply to comment #4) > Same problem here :-( > Shouldn´t the mp3 useflag for wine on AMD64 then not be masked? > Yeah, that sounds about right. If portage can't provide the 32-bit libmp3123 libraries through any direct means on the amd64 platform.... Not sure if this is portage's jurisdiction (since it's more a feature in the configure script we're barring because of lack of support for dependencies; It's not really a problem). Technically a user can get a hold of the 32-bit libmp3 libraries... after which point our ebuild would be incomplete if this user were trying to compile this functionality in. Does portage do any kind of "tiered"/ordered useflag building? Like a kind of: 1) globals in make.conf 2) global overrides in ebuild 3) package.use 4) disabled in ebuild Just a thought... the above would really help here :/ In any case, there's package.use for those who need to blacklist it manually for now.
Until portage has proper multilib package building support (a la the multilib-overlay), 32-bit libraries like mpg123 SHOULD be provided by: app-emulation/emul-linux-x86-soundlibs Currently this package is extremely outdated. Potential solutions: 1) mask the flag on 64-bit arch until portage has full multilib building support in packages like media-sound/mpg123 2) Update app-emulation/emul-linux-x86-soundlibs to have media-sound/mpg123 Note that for solution 2, you will also run into this upstream bug: http://www.nabble.com/Build-failure-on-current-git-tt25120750.html
> Potential solutions: > > 1) mask the flag on 64-bit arch until portage has full multilib building > support in packages like media-sound/mpg123 Yeah, that sounds correct based on that other problem you mentioned. If we do it that way, people who be interested in using self-provided mpg123 libraries on an amd64 system, would be required to manually unmask the mp3 use flag in their /etc/portage/; so we wouldn't be blocking any potential functionality by doing this. I agree. profiles/default-linux/amd64/package.use.mask :)
*** Bug 283870 has been marked as a duplicate of this bug. ***
%% cvs di Index: package.use.mask =================================================================== RCS file: /var/cvsroot/gentoo-x86/profiles/arch/amd64/package.use.mask,v retrieving revision 1.38 diff -u -r1.38 package.use.mask --- package.use.mask 4 Aug 2009 10:28:26 -0000 1.38 +++ package.use.mask 6 Sep 2009 23:50:31 -0000 @@ -18,6 +18,10 @@ #--- END OF EXAMPLES --- +# Jeremy Olexa <darkside@gentoo.org> (06 Sep 2009) +# Mask wine[mp3] because it fails to build. bug 283860 +app-emulation/wine mp3 + # Dawid Węgliński <cla@gentoo.org> # Mask amarok2 useflag for net-im/kadu # See bug #238487 for references
And now that this is closed, how will the next developer building emul- package know that he needs to add libmpg123.so to the package? *polishes magic lamp*
indeed, resolving bugs by removing features is bad habit. btw, file a new bug?
*** Bug 283902 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > indeed, resolving bugs by removing features is bad habit. > > btw, file a new bug? > (In reply to comment #13) > And now that this is closed, how will the next developer building emul- package > know that he needs to add libmpg123.so to the package? > > *polishes magic lamp* > The summary says "fails to build with USE=mp3" either change the summary to reflect an emul-* change and reopen or open a new bug. I don't care.
If you open a new bug for this issue please CC me on it. FWIW, I investigated the other issue I mentioned in comment #9, and the problem there is that mpg123 creates an ABI-dependant mpg123.h file. The one generated by the proper mpg123 package on amd64 will only work correctly for 64-bit builds against it. There's a prep_ml_includes function in multilib.eclass to deal with this situation, but I'm not sure it'd work directly here, since the 64-bit build and 32-bit "build" are in separate packages. The general approach would work, but resolving the file collision would be tricky.
bug 283912 is the feature request for app-emulation/emul-linux-x86-soundlibs
With new app-emulation/emul-linux-x86-soundlibs-20091226 wine still fails to build due to [dlls/winemp3.acm/]mpegl3.c:(.text+0x141): undefined reference to `mpg123_feedseek' Found on appdb that mpg123_feedseek should be replaced with mpg123_feedseek_64 on amd64 systems, but I haven't tried it yet
Seems that it's not only affecting to Gentoo: https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/456132
And upstream bug: http://bugs.winehq.org/show_bug.cgi?id=20042
This problem occurs because /usr/include/mpg123.h is ABI sensitive. The solution to this problem is implemented in the portage-multilib project overly, which is to make the above-named file a wrapper that pulls in the correct .h file depending on the gcc macros __i386__ and __x86_64__ (see the bottom of multilib.eclass for the prep_ml_includes function which does this for you). Unfortunately, in current portage, this would require some kind of cooperation between the 64-bit built mpg123 package and the emul-linux-x86-soundlibs package: which would own the mpg123.h file? What would it look like in the absence of the emul-linux-x86-soundlibs package on the system?
Hack from http://bugs.winehq.org/show_bug.cgi?id=20042#c21 works for me Is it really more wine bug than mpg123 bug, due to what ferret said?
(In reply to comment #21) > And upstream bug: > http://bugs.winehq.org/show_bug.cgi?id=20042 > I opened bug 299490 for this problem to stop polluting this one
It's not a wine issue. Any 32-bit program depending on mpg123 that you try to build on amd64 in gentoo will currently fail.
