On Do, Aug 22, 2013 at 00:32:12 (CEST), Thomas Orgis wrote: > Well, those look fine to me: > > checking for size_t... yes > checking for uintptr_t... yes > checking for ssize_t... yes > checking for off_t... yes > checking for int32_t... yes > checking for uint32_t... yes > checking for int16_t... yes > checking for uint16_t... yes > checking size of size_t... 4 > checking size of ssize_t... 4 > checking size of off_t... 8 > checking size of int32_t... 4 > checking size of long... 4 > > The whole point of large file support is to have off_t with 64 bit on a > 32 bit platform. But the lines before these explain some confusion: > > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > > _FILE_OFFSET_BITS is not set for mpg123 build. The normal build should > use 64 bit offsets, but the macro code renaming things to _64 suffix is > not active during mpg123 build, as it depends on that variable. Now, > MPlayer, and also mplayer2 build does that > > > cc [...] -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE > [...] -c -o libmpcodecs/ad_mpg123.o libmpcodecs/ad_mpg123.c > > That is the reason why I added the LFS alias functions. This practice > of enforcing the offset bits also on a 64 bit box prompted the need to > always provide _64 functions even if this is the natic off_t without > large file support hackery. > > The issue at hand is that the AC_SYS_LARGEFILE macro mpg123 uses for > configuring figures that it does not need _FILE_OFFSET_BITS. To sum it > up, here is a quote from configure.ac: > > dnl Detect large file support, enable switches if needed. > AC_SYS_LARGEFILE > dnl If we do have a switch for large files, rename off_t-aware API calls. > dnl Using the file_offset_bits variable here is fine for linux (possibly > Solaris), > dnl Others... we'll have to see. > > I guess kfreebsd counts as "others". One could just use the diagnostic > of the size of off_t and whether it differs from long int ...
That would then make mpg123 export the _64 variants in the library. Is this the correct behavior, even on systems that do have a 64bit off_t such as kfreebsd-i386? Your answer seems a bit inconclusive here to me. Wouldn't it make sense for mpg123 always export these symbols, even when they are "only" simple aliases on those archs? > short-time fix for mplayer2 would be to drop _FILE_OFFSET_BITS (undef > in ad_mpg123.c before loading mpg123.h) as this indeed does not seem to > be needed on kfreebsd. I was considering doing that, but I wonder if that was fix, or a workaround? > Could someone who works on that one confirm that it always defaults to > 64 bit off_t? I'm not sure if I understand the question, what does "it" refer to? kfreebsd-i386, mplayer2 or mpg123? Thank you for your very prompt response! Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
