[mpg123-devel] [ mpg123-Bugs-3314817 ] Large file support broken with MinGW
Brought to you by:
sobukus
From: SourceForge.net <no...@so...> - 2011-06-11 14:17:18
|
Bugs item #3314817, was opened at 2011-06-11 02:49 Message generated for change (Comment added) made by jon_y You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=733194&aid=3314817&group_id=135704 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mpglib Group: 1.13.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Lindgren (jpl1990) Assigned to: Nobody/Anonymous (nobody) Summary: Large file support broken with MinGW Initial Comment: I am trying to compile Audacious in MinGW dynamically linking to libmpg123. Audacious uses -D_FILE_OFFSET_BITS=64 in its CFLAGS, which seems to cause problems with mpg123. I tried building mpg123 with -D_FILE_OFFSET_BITS=64: $ CFLAGS="-D_FILE_OFFSET_BITS=64" ./configure $ make Which gives the following errors: .libs/lfs_alias.o:lfs_alias.c:(.text+0x17): undefined reference to `mpg123_open' .libs/lfs_alias.o:lfs_alias.c:(.text+0x37): undefined reference to `mpg123_open_fd' If I build mpg123 without -D_FILE_OFFSET_BITS=64: $ ./configure $ make Then it builds, but Audacious cannot link to it: c:\audacious-plugins\src\mpg123/mpg123.c:163: undefined reference to `mpg123_replace_reader_handle_64' c:\audacious-plugins\src\mpg123/mpg123.c:165: undefined reference to `mpg123_open_handle_64' So currently it's a lose-lose situation. ---------------------------------------------------------------------- Comment By: Jonathan Yong (jon_y) Date: 2011-06-11 22:17 Message: 1. You can't have it both ways, either mpg123 use only a single ABI that breaks depending on -D_FILE_OFFSET_BITS=64, or you have this situation. 2. That's because you defined -D_FILE_OFFSET_BITS=64 without fully knowing its impact. Its fragile, it breaks ABI, don't use it without checking AC_SYS_LARGEFILE. ---------------------------------------------------------------------- Comment By: John Lindgren (jpl1990) Date: 2011-06-11 21:45 Message: > 1. Keep mpg123 as it is, nothing is wrong with it. I disagree. mpg123.h should not declare functions that are not present in the library as installed. The fact that _FILE_OFFSET_BITS may have no effect in MinGW (I haven't checked this) doesn't mean that it's okay for mpg123 to break when an application uses _FILE_OFFSET_BITS. > 3. Fix Audacious to use AC_SYS_LARGEFILE Ironically, we began using _FILE_OFFSET_BITS explicitly in an attempt to link dynamically with previous, broken versions of your library on Linux, because AC_SYS_LARGEFILE did *not* work at that time. Make up your minds, people. ---------------------------------------------------------------------- Comment By: Jonathan Yong (jon_y) Date: 2011-06-11 21:24 Message: I don't think its a good idea to add platform specific exceptions, especially if its this fragile. MinGW from mingw.org normally ignores _FILE_OFFSET_BITS, so the Audacious devs might think its OK to define it anyway. This runs afoul of mpg123's headers. mingw-w64 (both 32bit and 64bit) offers some LFS macros that respond to _FILE_OFFSET_BITS they are working, so far. Here's what I think: 1. Keep mpg123 as it is, nothing is wrong with it. 2. Stop using CFLAGS that way, especially if it messes with ABI. 3. Fix Audacious to use AC_SYS_LARGEFILE ---------------------------------------------------------------------- Comment By: Thomas Orgis (sobukus) Date: 2011-06-11 20:27 Message: Should the mpg123 header work out that it's being used in MinGW and ignore _FILE_OFFSET_BITS? And, well ... if 32bit MinGW really doesn't have this LFS stuff, won't audacious run into trouble assuming it does? I'm guessing in the dark here, as I don't work on Windows machines ... hence, I hope you two can settle this, perhaps bringing in (more) Audacious folks into play, too? ---------------------------------------------------------------------- Comment By: Jonathan Yong (jon_y) Date: 2011-06-11 20:16 Message: I meant without messing with CFLAGS. Autotools doesn't set it at all unless it has any effects, the test macros will detect that MinGW doesn't have any of those and will not set _FILE_OFFSET_BITS. If you are setting it implicitly without any checks in configure.ac, you're using autotools wrong. ---------------------------------------------------------------------- Comment By: John Lindgren (jpl1990) Date: 2011-06-11 19:43 Message: I did try --disable-lfs-alias as a workaround; see my last comment. > I don't understand why Audacious needs to mess with CFLAGS. Name *one* program using GNU autoconf that doesn't set any kind of CFLAGS. ---------------------------------------------------------------------- Comment By: Jonathan Yong (jon_y) Date: 2011-06-11 09:43 Message: I don't understand why Audacious needs to mess with CFLAGS. MinGW doesn't have such wrappers and it would be wrong to define them. What would happen if you just used --disable-lfs-alias? Alternatively, you can retry with mingw-w64, which has LFS wrappers. ---------------------------------------------------------------------- Comment By: John Lindgren (jpl1990) Date: 2011-06-11 02:59 Message: Found a workaround: $ CFLAGS="-D_FILE_OFFSET_BITS=64" ./configure --disable-lfs-alias ---------------------------------------------------------------------- Comment By: John Lindgren (jpl1990) Date: 2011-06-11 02:59 Message: Found a workaround: $ CFLAGS="-D_FILE_OFFSET_BITS=64" ./configure --prefix=/C/aud --disable-lfs-alias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=733194&aid=3314817&group_id=135704 |