Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386

[Reinhard Tartler]

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