http://bugs.winehq.org/show_bug.cgi?id=20042
Summary: Wine does not build on amd64 when linking to 32-bit libmpg123 Product: Wine Version: 1.1.29 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: build-env AssignedTo: wine-bugs@winehq.org ReportedBy: scott@open-vote.org
I'm not 100% sure this isn't a distribution issue, however I couldn't think of anything else to do so I'm reporting it here in case there's something obvious in Wine I've missed.
Essentially, I've added libmpg123-dev to the build depends in the latest Wine package, and it seems to build fine on i386:
http://launchpadlibrarian.net/31760091/buildlog_ubuntu-karmic-i386.wine1.2_1...
However, doing the same thing on amd64 generates a build failure, even after I've added a 32 bit version of libmpg123-0 to the ia32-libs package (and thus I have /usr/lib32/libmpg123.so, /usr/lib32/libmpg123.so.0, and /usr/lib32/libmpg123.so.0.14.3)
Configure detects /usr/include/mpg123.h as usable, however build later fails with: mpegl3.o: In function `MPEG3_Reset': /build/buildd/wine1.2-1.1.29/dlls/winemp3.acm/mpegl3.c:401: undefined reference to `mpg123_feedseek'
You can see the build log here (compare with the first one above) -- search for mpg123 to get to the relevant stuff:
http://launchpadlibrarian.net/31759796/buildlog_ubuntu-karmic-amd64.wine1.2_...
If it's relevant, the libmpg123 version is 1.7.2
http://bugs.winehq.org/show_bug.cgi?id=20042
Scott Ritchie scott@open-vote.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@open-vote.org
--- Comment #1 from Scott Ritchie scott@open-vote.org 2009-09-14 09:13:54 --- I'll attach a patch soon, but I found that changing: mpg123_feedseek(aad->mh, 0, SEEK_SET, NULL); to mpg123_feedseek_64(aad->mh, 0, SEEK_SET, NULL); in mpegl3.c fixed building. This is because for some reason the 32-bit symbol export is named mpg123_feedseek_64; I think the builder was getting confused by the existence of a default 64-bit feedseek on amd64 (and thus not using the _64 function in the 32 bit library)
http://bugs.winehq.org/show_bug.cgi?id=20042
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #2 from Scott Ritchie scott@open-vote.org 2009-09-14 18:28:42 --- Created an attachment (id=23601) --> (http://bugs.winehq.org/attachment.cgi?id=23601) Fix build failure on amd64 by forcing 32 bit symbol
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #3 from Austin English austinenglish@gmail.com 2009-09-14 20:10:39 --- (In reply to comment #2)
Created an attachment (id=23601)
--> (http://bugs.winehq.org/attachment.cgi?id=23601) [details]
Fix build failure on amd64 by forcing 32 bit symbol
Doesn't work for me on 64-bit karmic, for 32-bit or 64-bit wine: austin@midna:~/wine-git/dlls/winemp3.acm$ make ccache gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o mpegl3.o mpegl3.c mpegl3.c: In function ‘MPEG3_Reset’: mpegl3.c:401: warning: implicit declaration of function ‘mpg123_feedseek_64’ ../../tools/winegcc/winegcc -m32 -B../../tools/winebuild --sysroot=../.. -shared ./winemp3.acm.spec mpegl3.o -o winemp3.acm.so -lwinmm -luser32 -lkernel32 ../../libs/port/libwine_port.a -lmpg123 ../../tools/winegcc/winegcc -m32 -B../../tools/winebuild --sysroot=../.. -shared ./winemp3.acm.spec mpegl3.o -o winemp3.acm.fake -lwinmm -luser32 -lkernel32 ../../libs/port/libwine_port.a -lmpg123
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #4 from Austin English austinenglish@gmail.com 2009-09-14 22:42:48 --- But does work with/without the patch on 32-bit karmic.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #5 from Scott Ritchie scott@open-vote.org 2009-09-15 00:35:56 --- Apparently there may have been API changes between Ubuntu 9.04 and 9.10, most notably the upgrade of libmpg123 1.4 to 1.7.2. I can further raise this to 1.7.3 or even 1.9 if needed.
http://www.mpg123.de/cgi-bin/news.cgi
Have you tested your code with newer libmpg123's on 9.04?
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #6 from Austin English austinenglish@gmail.com 2009-09-15 10:57:35 --- (In reply to comment #5)
Apparently there may have been API changes between Ubuntu 9.04 and 9.10, most notably the upgrade of libmpg123 1.4 to 1.7.2. I can further raise this to 1.7.3 or even 1.9 if needed.
http://www.mpg123.de/cgi-bin/news.cgi
Have you tested your code with newer libmpg123's on 9.04?
Was that a question for me, or Aric?
http://bugs.winehq.org/show_bug.cgi?id=20042
3vi1 winehq.org@eternaldusk.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq.org@eternaldusk.com
--- Comment #7 from 3vi1 winehq.org@eternaldusk.com 2009-09-23 06:49:31 --- I started seeing this exact issue just yesterday. I'm using 1.7.3 of libmpg123-dev, which is now the version in the repos for 64-bit 9.10 (Kubuntu).
Scott's fix corrects the compilation problem for me.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #8 from Scott Ritchie scott@open-vote.org 2009-09-23 07:22:27 --- The fix isn't a real fix, you might as well just build without libmpg123-dev
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #9 from 3vi1 winehq.org@eternaldusk.com 2009-09-23 16:02:01 --- (In reply to comment #8)
The fix isn't a real fix, you might as well just build without libmpg123-dev
Ahh... Thx for the heads up.
http://bugs.winehq.org/show_bug.cgi?id=20042
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
http://bugs.winehq.org/show_bug.cgi?id=20042
Jan Simek jsimek.cz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|austinenglish@gmail.com, |jsimek.cz@gmail.com |nerv@dawncrow.de, | |scott@open-vote.org, | |winehq.org@eternaldusk.com |
http://bugs.winehq.org/show_bug.cgi?id=20042
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
http://bugs.winehq.org/show_bug.cgi?id=20042
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com, | |winehq.org@eternaldusk.com
http://bugs.winehq.org/show_bug.cgi?id=20042
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu
--- Comment #10 from Erich Hoover ehoover@mines.edu 2009-10-29 16:11:38 --- (In reply to comment #8)
The fix isn't a real fix, you might as well just build without libmpg123-dev
I just upgraded and I didn't need to do anything to get a 32-bit libmpg123.so. It seems to me that libmpg123-dev header file should be mapping mpg123_feedseek to mpg123_feedseek_64, the other symbols seem to be OK though so I wouldn't say that's the same as building without libmpg123-dev.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #11 from Austin English austinenglish@gmail.com 2009-10-30 22:48:57 --- (In reply to comment #10)
(In reply to comment #8)
The fix isn't a real fix, you might as well just build without libmpg123-dev
I just upgraded and I didn't need to do anything to get a 32-bit libmpg123.so. It seems to me that libmpg123-dev header file should be mapping mpg123_feedseek to mpg123_feedseek_64, the other symbols seem to be OK though so I wouldn't say that's the same as building without libmpg123-dev.
Still doesn't work here.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #12 from Erich Hoover ehoover@mines.edu 2009-10-31 00:47:08 --- (In reply to comment #11)
(In reply to comment #10)
(In reply to comment #8)
The fix isn't a real fix, you might as well just build without libmpg123-dev
I just upgraded and I didn't need to do anything to get a 32-bit libmpg123.so. It seems to me that libmpg123-dev header file should be mapping mpg123_feedseek to mpg123_feedseek_64, the other symbols seem to be OK though so I wouldn't say that's the same as building without libmpg123-dev.
Still doesn't work here.
What version of ia32-libs do you have? The name for the feedseek symbol is still "wrong" for the version I have (2.7ubuntu17), but it does at least include a 32-bit libmpg123: ehoover@ubuntu:~$ dlocate libmpg123.so libmpg123-dev: /usr/lib/libmpg123.so ia32-libs: /usr/lib32/libmpg123.so.0.14.4 ia32-libs: /usr/lib32/libmpg123.so.0 ia32-libs: /usr/lib32/libmpg123.so libmpg123-0: /usr/lib/libmpg123.so.0.14.4 libmpg123-0: /usr/lib/libmpg123.so.0
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #13 from Austin English austinenglish@gmail.com 2009-10-31 00:52:02 --- (In reply to comment #12)
What version of ia32-libs do you have? The name for the feedseek symbol is still "wrong" for the version I have (2.7ubuntu17), but it does at least include a 32-bit libmpg123: ehoover@ubuntu:~$ dlocate libmpg123.so libmpg123-dev: /usr/lib/libmpg123.so ia32-libs: /usr/lib32/libmpg123.so.0.14.4 ia32-libs: /usr/lib32/libmpg123.so.0 ia32-libs: /usr/lib32/libmpg123.so libmpg123-0: /usr/lib/libmpg123.so.0.14.4 libmpg123-0: /usr/lib/libmpg123.so.0
austin@midna:~/wine-git/tools/winebuild$ dlocate libmpg123.so libmpg123-dev: /usr/lib/libmpg123.so ia32-libs: /usr/lib32/libmpg123.so.0.14.4 ia32-libs: /usr/lib32/libmpg123.so.0 ia32-libs: /usr/lib32/libmpg123.so libmpg123-0: /usr/lib/libmpg123.so.0.14.4 libmpg123-0: /usr/lib/libmpg123.so.0
austin@midna:~/wine-git/tools/winebuild$ dpkg -l | grep ia32 ii ia32-libs 2.7ubuntu17 ia32 shared libraries for use on amd64 and i
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #14 from André H. nerv@dawncrow.de 2009-10-31 05:08:09 --- $ dlocate libmpg123.so libmpg123-dev: /usr/lib/libmpg123.so ia32-libs: /usr/lib32/libmpg123.so.0.14.4 ia32-libs: /usr/lib32/libmpg123.so.0 ia32-libs: /usr/lib32/libmpg123.so libmpg123-0: /usr/lib/libmpg123.so.0.20.2 libmpg123-0: /usr/lib/libmpg123.so.0
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #15 from Erich Hoover ehoover@mines.edu 2009-10-31 14:59:00 --- (In reply to comment #13)
... austin@midna:~/wine-git/tools/winebuild$ dlocate libmpg123.so libmpg123-dev: /usr/lib/libmpg123.so ia32-libs: /usr/lib32/libmpg123.so.0.14.4 ia32-libs: /usr/lib32/libmpg123.so.0 ia32-libs: /usr/lib32/libmpg123.so libmpg123-0: /usr/lib/libmpg123.so.0.14.4 libmpg123-0: /usr/lib/libmpg123.so.0
austin@midna:~/wine-git/tools/winebuild$ dpkg -l | grep ia32 ii ia32-libs 2.7ubuntu17 ia32 shared libraries for use on amd64 and i
Ok, I think there's a bit of a miscommunication here - my response was intended to touch on the comment "even after I've added a 32 bit version of libmpg123-0 to the ia32-libs package." I was trying to say that my ia32-libs already had a 32-bit libmpg123.
My other comments indicated that what I believe is the problem is that libmpg123-dev is distributing an incorrect header file for the purposes of linking to the 32-bit version of the library. I would say that the header file should be testing the architecture to determine the symbol names, look near the comment: /* Redefine names of functions dealing with file and file offsets ...everything handling off_t, for example, which can be 32 or 64 bits. */
Since you can see that the symbol names are different between the 32-bit and 64-bit versions: ehoover@ubuntu:/usr/lib64$ nm -D libmpg123.so | grep feedseek 0000000000012ef0 T mpg123_feedseek ehoover@ubuntu:/usr/lib32$ nm -D libmpg123.so | grep feedseek 000141f0 T mpg123_feedseek_64
http://bugs.winehq.org/show_bug.cgi?id=20042
Scott Ritchie scott@open-vote.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@open-vote.org
--- Comment #16 from Scott Ritchie scott@open-vote.org 2009-11-01 12:08:01 --- "Ok, I think there's a bit of a miscommunication here - my response was intended to touch on the comment "even after I've added a 32 bit version of libmpg123-0 to the ia32-libs package." I was trying to say that my ia32-libs already had a 32-bit libmpg123."
Just to clarify, I was responsible for actually putting libmpg123-0 into the distribution ia32-libs package. You have it because I added and uploaded it earlier.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #17 from Erich Hoover ehoover@mines.edu 2009-11-01 15:27:19 --- (In reply to comment #16)
"Ok, I think there's a bit of a miscommunication here - my response was intended to touch on the comment "even after I've added a 32 bit version of libmpg123-0 to the ia32-libs package." I was trying to say that my ia32-libs already had a 32-bit libmpg123."
Just to clarify, I was responsible for actually putting libmpg123-0 into the distribution ia32-libs package. You have it because I added and uploaded it earlier.
Sorry I wasted all of those comments then, I was not aware that you had corrected that for all of us. Since you have the power, you could compile a 32-bit libmpg123-0 that uses 32-bit file offsets: CFLAGS="-m32" ./configure --disable-largefile
If you do that then the compiled library will have the expected symbols (ie. mpg123_feedseek instead of mpg123_feedseek_64).
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #18 from Scott Ritchie scott@open-vote.org 2009-11-01 15:40:42 --- Is that a switch that should be passed to building on all arches, or just 32 bit?
Currently the way ia32-libs works is very ugly - the libs are copied directly from the 32 bit package and dumped to /usr/lib32. This means that packages which have hard-coded paths pointing to /usr/lib will sometimes run into the 64-bit version of the package on the system, resulting in errors.
The header file itself comes from the -dev package that was built on 64 bit (I believe because it's assumed that the header file doesn't change between arches).
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #19 from Erich Hoover ehoover@mines.edu 2009-11-01 15:59:51 --- (In reply to comment #18)
Is that a switch that should be passed to building on all arches, or just 32 bit?
I believe that this flag should only be passed when building a 32-bit compatibility library for use on a 64-bit system. Since the library is aware of "large file support" (and the generic 32-bit build doesn't have large file support enabled) you end up with a mismatch in the size of the "off_t" type. So, if you don't turn on the flag you'll build the library with 8-byte file offsets instead of 4-byte file offsets.
Currently the way ia32-libs works is very ugly - the libs are copied directly from the 32 bit package and dumped to /usr/lib32. This means that packages which have hard-coded paths pointing to /usr/lib will sometimes run into the 64-bit version of the package on the system, resulting in errors.
While I'm sure you have a lot more experience with it than I, from an end-user perspective I tend to agree. Personally, I think that ia32-libs should be a metapackage with separate packages for the different libraries.
The header file itself comes from the -dev package that was built on 64 bit (I believe because it's assumed that the header file doesn't change between arches).
I've run into some rare header files change behavior between 32-bit and 64-bit. When that is the case it is sometimes necessary to test for defined(__i386) or defined(__x86_64) so that a separate header file is not needed for the two architectures.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #20 from Scott Ritchie scott@open-vote.org 2009-11-01 16:23:28 ---
I believe that this flag should only be passed when building a 32-bit compatibility library for use on a 64-bit system. Since the library is aware of "large file support" (and the generic 32-bit build doesn't have large file support enabled) you end up with a mismatch in the size of the "off_t" type. So, if you don't turn on the flag you'll build the library with 8-byte file offsets instead of 4-byte file offsets.
If it's harmless on a 32 bit build for 32 bit systems then I can just tell the package to always use that switch for that arch. Is that the case?
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #21 from Erich Hoover ehoover@mines.edu 2009-11-01 17:07:04 --- Created an attachment (id=24513) --> (http://bugs.winehq.org/attachment.cgi?id=24513) Patch for mpg123.h to match symbol names for both 32-bit and 64-bit compilation
(In reply to comment #20)
... If it's harmless on a 32 bit build for 32 bit systems then I can just tell the package to always use that switch for that arch. Is that the case?
Well, it's not harmless is part of the issue - if large file support is enabled then the package could have problems if you try to use it with a large file (> 2 GB). After downloading the pre-packaged 32-bit libmpg123-0 and taking a look at the symbols it appears that my assessment was actually wrong. Large file support actually IS enabled on 32-bit ubuntu: ehoover@ubuntu:~/libmpg123-i386-deb/usr/lib$ nm -D libmpg123.so.0.14.4 | grep feedseek 000141f0 T mpg123_feedseek_64
So, that puts us back to fixing the header file. If you apply the attached patch to your /usr/include/mpg123.h then it will choose the correct symbol names depending on the architecture. If you compile libmpg123 with and without the "-m32" flag you will see that you get a different mpg123.h header file, so the "distributed" version should really handle both cases.
http://bugs.winehq.org/show_bug.cgi?id=20042
Xavier Vachon xvachon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xvachon@gmail.com
--- Comment #22 from Xavier Vachon xvachon@gmail.com 2010-01-18 12:23:23 --- Confirming this bug with latest git (1.1.36)
http://bugs.winehq.org/show_bug.cgi?id=20042
Thomas Orgis thomas-forum@orgis.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thomas-forum@orgis.org
--- Comment #23 from Thomas Orgis thomas-forum@orgis.org 2010-01-19 17:27:29 --- Hi. The mpg123 project speaking here.
As you already noticed, the simple issue is that you need to build you app using the mpg132 header that matches the build of libmpg123 you're linking to. That is nothing esoteric. That this is causing trouble in this case is for the simple fact that large file support is a bit on the dangerous side on Linux (or Solaris, for that matter): I added the _64 suffixes for the builds that need to have largefile support explicitly enabled (with 64 bits).
That technique prevents a program that expects 32 bit file offsets to link to a library that uses 64 bits. I do not want to see the bugs that arise when people run their little test programs and forget the proper LARGEFILE_BITS setting for the compiler.
So, the mpg123 header is architecture-dependent (actually, build-time configuration-dependent) and so multilib installations should treat it accordingly. One way is to make /usr/include/mpg123.h a stub that checks the current arch / largefile setup and includes the proper specific header.
I do not see a bug at either the wine or mpg123 side... You simply need to use a consistent build setup. Trying to use headers from the 32 bit system and linking to 64 bit libraries is not consistent.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #24 from Scott Ritchie scott@open-vote.org 2010-01-19 17:53:29 --- You're correct Thomas, the bug is at the Ubuntu side, however we can't solve this properly until we have true multiarch support in the package manager. This is a project that has been a long time coming, but now it appears like it won't be integrated into the distribution until Lucid + 1, or October.
In the meantime I'm going to experiment with Erich's patch as a temporary workaround for the next release -- is there anything in it you see that would be bad? Thank you for commenting :)
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #25 from Thomas Orgis thomas-forum@orgis.org 2010-01-19 18:52:25 --- The patch idea looks fine to me for your specific situation: Handle either i386 with large file support enabled or plain x86-64. I hope you understand that I am reluctant to provide such a header with the mpg123 installation, though. The mpg123 install does not know what different setups the installed header should cater for, the distributor knows.
Interesting insight: This issue of incompatible headers apparently didn't bother distros over the several years there is multilib support in the field -- or did they just apply hacks silently? Now, I suddenly read about plans for proper multilib handling also respecting headers in both ubuntu and gentoo (my own distro, Source Mage, rather decided not to do multilib at all, we just have/had a package with 32bit libs in a separate prefix to make some stuff work). Well, perhaps mpg123 can help to push people in the right direction to make the multiarch setup more robust -- so, thanks to the wine project for providing the obvious use-case for 32 bit stuff on a 64 bit system: Still run StarCraft* sort-of natively on your 64 bit Linux install;-)
* Yeah, I'm still longing for that DIB engine, though... drawing 8bit sprites in VGA resolution really shouldn't take up that much CPU:-/
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #26 from Xavier Vachon xvachon@gmail.com 2010-02-01 11:54:50 --- With current git (1.1.37, Feb. 1), the hack for mpg123.h fails.
See here : http://pastebin.ca/1774529
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #27 from Erich Hoover ehoover@mines.edu 2010-02-01 12:00:26 --- (In reply to comment #26)
With current git (1.1.37, Feb. 1), the hack for mpg123.h fails.
See here : http://pastebin.ca/1774529
The patch is not for Wine, it is for the header included with mpg123 (/usr/include/mpg123.h).
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #28 from Xavier Vachon xvachon@gmail.com 2010-02-01 12:21:12 --- (In reply to comment #27)
(In reply to comment #26)
With current git (1.1.37, Feb. 1), the hack for mpg123.h fails.
See here : http://pastebin.ca/1774529
The patch is not for Wine, it is for the header included with mpg123 (/usr/include/mpg123.h).
I know, we already emailed each other about that.
I forgot to mention, Gentoo made an ebuild for the latest version of mpg123 (1.10.0). The hack failed with the updated version of mpg123.h .
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #29 from Erich Hoover ehoover@mines.edu 2010-02-01 12:30:15 --- (In reply to comment #28)
(In reply to comment #27)
(In reply to comment #26)
With current git (1.1.37, Feb. 1), the hack for mpg123.h fails.
See here : http://pastebin.ca/1774529
The patch is not for Wine, it is for the header included with mpg123 (/usr/include/mpg123.h).
I know, we already emailed each other about that.
I forgot to mention, Gentoo made an ebuild for the latest version of mpg123 (1.10.0). The hack failed with the updated version of mpg123.h .
Sorry about that, I saw "can't find file to patch" and jumped to conclusions. You'll need to post the header file so I can see what is different.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #30 from Xavier Vachon xvachon@gmail.com 2010-02-01 14:16:15 --- Created an attachment (id=26010) --> (http://bugs.winehq.org/attachment.cgi?id=26010) mpg123.h
(In reply to comment #29)
(In reply to comment #28)
(In reply to comment #27)
(In reply to comment #26)
With current git (1.1.37, Feb. 1), the hack for mpg123.h fails.
See here : http://pastebin.ca/1774529
The patch is not for Wine, it is for the header included with mpg123 (/usr/include/mpg123.h).
I know, we already emailed each other about that.
I forgot to mention, Gentoo made an ebuild for the latest version of mpg123 (1.10.0). The hack failed with the updated version of mpg123.h .
Sorry about that, I saw "can't find file to patch" and jumped to conclusions. You'll need to post the header file so I can see what is different.
As requested.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #31 from Erich Hoover ehoover@mines.edu 2010-02-01 16:35:19 --- Created an attachment (id=26015) --> (http://bugs.winehq.org/attachment.cgi?id=26015) Patch for mpg123.h to match symbol names for both 32-bit and 64-bit compilation [1.10.0]
The attached patch should do the trick for you.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #32 from Xavier Vachon xvachon@gmail.com 2010-02-02 11:13:22 --- (In reply to comment #31)
Created an attachment (id=26015)
--> (http://bugs.winehq.org/attachment.cgi?id=26015) [details]
Patch for mpg123.h to match symbol names for both 32-bit and 64-bit compilation [1.10.0]
The attached patch should do the trick for you.
Building Wine with today's git and your hack fails.
ccache gcc -m32 -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -o cubetexture.o cubetexture.c mpegl3.o: In function `MPEG3_Reset': /wine-git/dlls/winemp3.acm/mpegl3.c:399: undefined reference to `mpg123_feedseek' collect2: ld returned 1 exit status winegcc: ccache failed make[2]: *** [winemp3.acm.so] Error 2 make[2]: Leaving directory `/wine-git/dlls/winemp3.acm' make[1]: *** [winemp3.acm] Error 2 make[1]: *** Waiting for unfinished jobs....
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #33 from Xavier Vachon xvachon@gmail.com 2010-02-05 12:11:26 --- (In reply to comment #32)
(In reply to comment #31)
Created an attachment (id=26015)
--> (http://bugs.winehq.org/attachment.cgi?id=26015) [details] [details]
Patch for mpg123.h to match symbol names for both 32-bit and 64-bit compilation [1.10.0]
The attached patch should do the trick for you.
Building Wine with today's git and your hack fails.
ccache gcc -m32 -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -o cubetexture.o cubetexture.c mpegl3.o: In function `MPEG3_Reset': /wine-git/dlls/winemp3.acm/mpegl3.c:399: undefined reference to `mpg123_feedseek' collect2: ld returned 1 exit status winegcc: ccache failed make[2]: *** [winemp3.acm.so] Error 2 make[2]: Leaving directory `/wine-git/dlls/winemp3.acm' make[1]: *** [winemp3.acm] Error 2 make[1]: *** Waiting for unfinished jobs....
Reinstalling mpg123 and updating to current git (1.1.38) made the hack work this time.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #34 from Thomas Orgis thomas-forum@orgis.org 2010-02-11 03:32:59 --- Created an attachment (id=26198) --> (http://bugs.winehq.org/attachment.cgi?id=26198) mpg123.h from a 64-bit install of unreleased 1.10.1, providing MPG123_FORCE_LARGEFILE.
OK, folks, would this be a solution for you:
I added a preliminary mpg123 1.10.1 to our repo (svn://orgis.org/mpg123/tags/1.10.1) that has a tweaked mpg123.h.in, resulting in the attached file when installed on a x86-64 Linux system.
The change is this: You can build your 32-bit app using this 64-bit header by overriding the largefile machinery.
cc -D_FILE_OFFSET_BITS=64 -DMPG123_FORCE_LARGEFILE=_64 ...
If you want to link with a libmpg123 that does not have largefile support enabled, then you can even build with a 32-bit largefile-enabled header using the same techique
cc -DMPG123_FORCE_LARGEFILE= ...
Whatever value you give to MPG123_FORCE_LARGEFILE, it will replace any default suffix appended to largefile-ware functions. Of course, do this at your own risk... you have to ensure that the library you are linking in does match your largefile setup!
Now, with the attached header, or supposedly mpg123-1.10.1 installed, putting -DMPG123_FORCE_LARGEFILE=_64 into the CFLAGS of the wine build should make it use the correct symbols on a multilib setup with largefile support.
Comments? Shall I release this hack?
http://bugs.winehq.org/show_bug.cgi?id=20042
Thomas Orgis thomas-forum@orgis.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #26198|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #35 from Alexandre Julliard julliard@winehq.org 2010-02-11 04:13:59 --- It would be much nicer for libmpg123 to export both types of symbols, like glibc does, then it would work everywhere without nasty header file hacks. And using the same header on all platforms would be a lot nicer too.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #36 from Thomas Orgis thomas-forum@orgis.org 2010-02-11 09:06:50 --- I am not sure what to respond to this. I do have the suspicion that mpg123 is not alone with the issue of having to prevent bad combinations of applications and libraries using 32 bit or 64 bit off_t. Be reminded that the header would look identical for i386 and x86-64 would 64 bit off_t be the default on a 32bit build. This whole mess mainly arises because a default build of libmpg123 enables 64 bit offsets via configure but when you simply build a program using libmpg123 and do not specify special compiler flags, your program will use a 32 bit off_t.
Without the check I built into the header, this would cause funny unspecified behaviour when using the API that expects 64 bit offsets. I assume that there are libraries that let that just happen... and this is mostly not an issue because distributions carefully build everything with largefile support(?). In hindsight, I perhaps should have not added that check. Most people would not notice and be happy, some people would have strange issues...
Now, for the option of implementing both 32 bit and 64 bit API, just like libc. Is it really a good idea to recreate that hack in each library relying on the "magic" of off_t? It seems like the other real option is to use yet another custom typedef for offsets and internally convert between that and the actual off_t the library uses. That includes handling EOVERFLOW and friends. It is not fun. I'd rather avoid such cruft before doing it incorrectly. And also, what will a user of the library do? Especially if the user uses other libraries that yet again have other custom file offset types... there will be blind casts without checking.
I do not feel comfortable having to devise header machinery that corretly maps functions to wrappers that handle 32 bit / 64 bit conversion... I will need to add architecture-dependent macros... see that there only is 64 bit off_t on an x86_64 system; detect i386 systems that need _32 and _64 functions... and then prevent this all do do something on *BSD, where off_t is just 64 bits, period. Such a header would not be platform-independent. It would be specific to the set of platforms that are covered in the preprocessor machinery.
But I want to have my code portable, using off_t and detecting at configure-time if large file support shall be enabled is portable. Every line of complication to the header makes it more likely that some configuration will be broken without need.
I see the problem really with the distributions: When they do multilib, they need to store both verisons of the header file, each matching its library. For a distribution it is trivial to install a wrapper in /usr/include that includes a 32 bit or a 64 bit header depending on x86 / x86-64 (SPARC / SPARC64, PPC / PPC64) build being selected. That can be automated in the distribution's build system. They know what architectures / ABIs they support. They know what default compiler they support.
Until such proper solution is in place, the workaround I offered should do the trick. When wine is configured with largefile support for 32 bit code, it just needs to add -DMPG123_FORCE_LARGEFILE=_64 to its CPPFLAGS. That won't work for mpg123 versions < 1.10.1, but we cannot change the past, anyway.
If this is really not acceptable, I am open to further discussion...
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #37 from Erich Hoover ehoover@mines.edu 2010-02-11 10:06:51 --- (In reply to comment #36)
I am not sure what to respond to this. I do have the suspicion that mpg123 is not alone with the issue of having to prevent bad combinations of applications and libraries using 32 bit or 64 bit off_t. Be reminded that the header would look identical for i386 and x86-64 would 64 bit off_t be the default on a 32bit build. ...
I think this is part of the reason the Debian-based distros have been discussing plans for a better multiple-architecture repo system.
This whole mess mainly arises because a default build of libmpg123 enables 64 bit offsets via configure but when you simply build a program using libmpg123 and do not specify special compiler flags, your program will use a 32 bit off_t. ...
I guess the issue I see with this whole thing is that I would expect the function name to be linked to the size of off_t. So, I would expect that both on a 64-bit system and on a 32-bit system with large file support that a '_64' would be appended to the function names (I would probably append '_32' for 32-bit off_t, but that's me). With this method it's then up to the programmer to properly request large file support when including the headers, but requesting the incorrect large file support will cause the library to fail at the linking stage.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #38 from Thomas Orgis thomas-forum@orgis.org 2010-02-13 11:29:27 --- OK, last try. I really want to avoid having to support both 32 and 64 bit file offsets in the library. One reason might be that it is really not needed that much. We all build with support for large files, right?
Please have a look at the new preliminary mpg123-1.10.1: http://mpg123.org/download/mpg123-1.10.1-prerelease.tar.bz2
I now dropped the protection in the header that wanted to prevent misconfiguration of large file support and instead just blindly use the _FILE_OFFSET_BITS symbol that is defined when including the header. What you have _FILE_OFFSET_BITS == 64, you app will look for mpg123_open_64, if it is not defined, it will look for mpg123_open. Inconsistent setups will fail later at the linking stage, and any user must now figure out herself that the missing symbols are because of large file support mismatch.
I have a FAQ entry already because people did not understand the error message I wrote to explain the breakage... now I will add a new passage about "Missing symbol bla_64?!", pointing to the explanation that is already there. This 32/64 bit off_t mess is a crappy mess and painting over it does not help, obviously.
So, when you folks look at the prerelease version and the header it installs, which indeed is identical now for 32 or 64 bits -- are you happy? Will everyone upgrade to 1.10.1 once I release it to have this fixed (one can dream;-)?
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #39 from Erich Hoover ehoover@mines.edu 2010-02-13 12:57:01 --- (In reply to comment #38)
... I now dropped the protection in the header that wanted to prevent misconfiguration of large file support and instead just blindly use the _FILE_OFFSET_BITS symbol that is defined when including the header. What you have _FILE_OFFSET_BITS == 64, you app will look for mpg123_open_64, if it is not defined, it will look for mpg123_open. Inconsistent setups will fail later at the linking stage, and any user must now figure out herself that the missing symbols are because of large file support mismatch.
Sounds good to me. It's actually kind of surprising that there's not a standard include file for these features, since everyone "should" be using the same settings. Though, I also can't imagine why someone would have a 2 GiB mp3 file.
Anyway, if you wanted to provide a "universal" library you could require that your library be built with large file support and then typecast non-64 bit off_t calls.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #40 from Thomas Orgis thomas-forum@orgis.org 2010-02-14 10:09:34 --- (In reply to comment #39)
Anyway, if you wanted to provide a "universal" library you could require that your library be built with large file support and then typecast non-64 bit off_t calls.
Not that simple: The libmpg123 API also exchanges file descriptors (mpg123_open_fd()) ... typecasting does not help you much there. The library would need full dual mode and separate paths for 32 bit / 64 bit I/O. But, well, I hope that the change I did at least helps the distro builds and also makes a default custom build of wine work (when it enables large file support...). The whole 32/64 bit off_t mess was designed for a transitional period anyway... that period already is long enough (OK, don't compare it to the transition period to IPv6).
http://bugs.winehq.org/show_bug.cgi?id=20042
Scott Ritchie scott@open-vote.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #41 from Scott Ritchie scott@open-vote.org 2010-02-20 19:47:39 --- I have uploaded the prerelease package to Ubuntu 10.04 Lucid and enabled building with mpg123 on the latest Wine there, and everything seems to be working fine. Thank you everyone :)
http://bugs.winehq.org/show_bug.cgi?id=20042
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |
--- Comment #42 from Dmitry Timoshkov dmitry@codeweavers.com 2010-02-24 05:49:40 --- (In reply to comment #41)
I have uploaded the prerelease package to Ubuntu 10.04 Lucid and enabled building with mpg123 on the latest Wine there, and everything seems to be working fine. Thank you everyone :)
What exactly has been fixed in Wine? by which commit?
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #43 from Scott Ritchie scott@open-vote.org 2010-02-24 18:55:45 --- As I understood there was no change to be made in Wine itself when the host system could instead just provide the right header files. If that's wrong and this should also be worked around in Wine itself then I should leave it open.
http://bugs.winehq.org/show_bug.cgi?id=20042
Mehdi Yousfi-Monod mehdi.yousfi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mehdi.yousfi@gmail.com
--- Comment #44 from Mehdi Yousfi-Monod mehdi.yousfi@gmail.com 2010-05-10 08:32:45 --- I've updated to Ubuntu 64 Lucid Lynx and to wine 1.1.44, I do not need to apply Scott Ritchie' hack anymore, wine compiles fine with mpg123 enable. I'm not sure whether it comes from the new Ubuntu or wine 1.1.44 though...
http://bugs.winehq.org/show_bug.cgi?id=20042
Marcos sombra2eternity@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sombra2eternity@gmail.com
--- Comment #45 from Marcos sombra2eternity@gmail.com 2010-06-12 14:48:20 --- *** Bug 23129 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20042
Andrew Nguyen arethusa26@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID
--- Comment #46 from Andrew Nguyen arethusa26@gmail.com 2010-08-23 00:49:58 --- I think libmpg123 was appropriately changed to make building work, so I'm marking invalid as nothing was changed in Wine.
http://bugs.winehq.org/show_bug.cgi?id=20042
Andrew Nguyen arethusa26@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #47 from Andrew Nguyen arethusa26@gmail.com 2010-08-23 00:50:32 --- Closing the bug.
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #48 from Marcos sombra2eternity@gmail.com 2010-08-23 08:17:53 --- @Andrew Nguyen Some people like me are using old and LTS versions of ubuntu systems, where the 64bits mpg123 have wrong functions prototypes. I dont think wine needs to fix something, but maybe it will be good to keep this bug report another ubuntu release open because old systems users are still moving.
I marked myself a bug duplicated of this. No actual version of wine from git compile on my system without tweaking, and that avoid me to make successful regresions test. Maybe new bug reports will be opened for those with old systems if this bug is closed (or maybe not).
I just wanted to point that
http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #49 from Thomas Orgis thomas-forum@orgis.org 2011-04-30 03:22:39 CDT --- To conclude this ... since mpg123 1.12.0 we have a both largefile and non-largefile interfaces in the same library file. So, for a typical 32 bit libmpg123.so, there is mpg123_feedseek and mpg123_feedseek_64 in there. Since mpg123 1.12.2, there are even aliases like mpg123_feedseek_32 on 32 bit systems for the non-largefile variant, and mpg123_feedseek_64 on 64 bit systems for the one-and-only largefile variant.
The main point is: You define _FILE_OFFSET_BITS, the mpg123 header selects the functions according to that ... and the library should have the symbols for any variant. If one could only figure out now what is going wrong again in the gentoo build of wine ... see news on https://bugs.gentoo.org/show_bug.cgi?id=299490 .
-
wine-bugs＠winehq.org