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

[Thomas Orgis]

Am Thu, 22 Aug 2013 07:46:55 +0200
schrieb Reinhard Tartler <siretart at tauware.de>: 

> 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?

Yes, as mpg123 does that successfully on platforms I worked on so far.
There are usually 3 parts of the large-file-aware API:

1. without suffix for native setting (32 bit off_t on systems that need
   _FILE_OFFSET_BITS=64 for 64 bit), possibly wrappers to call the _64 functions
2. with _64 for enabled large-file support (actual function or an alias
   to native 64 bit)
3. with _32 for those who set _LARGE_FILE_BITS=32, alias to native
   without suffix

You see, this is a royal mess and hopefully agree with me that defining
off_t with varying sizes on the same platform as build-time choice is
madness. That's why very few libraries even try to handle that
correctly. Any of these function names can be an alias, wrapper or
actual libmpg123 function. Well, this mess is for me to care for as
maintainer. Users are only interested in the symbols with _32 and _64
being present.

> > 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?

Well, depends on you considering that unconditional definition of
_FILE_OFFSET_BITS in MPlayer builds the proper thing to do;-)
Depending on the nature of debian/kfreebsd, making the mpg123 header
ignore _FILE_OFFSET_BITS might be a better idea.

> > 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?

The platform kfreebsd-i386. My question is how the large file issue is
handled there. The mpg123 build log suggests to me that large file
support (64 bit off_t) is the one and only configuration (which would
be a good thing, in itself). Is that correct? Since people use mpg123
on "actual" *BSD systems since quite some time now, I suppose that
debian/kfreebsd differs from them in that respect, as it does with
respect to Linux.

The long-term fix would make the mpg123 build aware of that and trigger
generation of _64 functions as direct api calls, without suffix as
alias to those and _32 wrapper functions that map long int offsets to
the 64 bit ones. I cannot promise a time scale to work on that myself,
due to RL pressure. One needs to modify configure.ac to check the size
of off_t in case of empty _FILE_OFFSET_BITS setting from
AC_SYS_LARGEFILE and trigger generation of _64 functions (or, rather
_(8*sizeof(off_t) functions) if sizeof(off_t) != sizeof(long). This
should only cover modification of 

configure.ac
src/libmpg123/lfs_wrap.c
src/libmpg123/lfs_alias.c
src/libmpg123/mpg123.h.in

to handle an extra macro besides _FILE_OFFSET_BITS to decide for
suffix for primary API. It would not be right to just force
_FILE_OFFSET_BITS=64 in configure.ac for that case, as this will cause
_32 functions mapping 32 bit long int arguments to off_t, which is
always 64 bit. And actually, this is the exact problem you already have
with the current configure.ac ... only without the benefit of having
_64 functions.

You need to separate two use cases of mpg123.h: Sorting out the symbols
of the libmpg123 build and mapping to the right ones when building a
client application.

Yeah, I'm convinced now: The mpg123 build is broken right now on this
platform, as long as any user decides to define _FILE_OFFSET_BITS. The
result will either be unresolved symbols (=64) or undefined behaviour
(=32 ... handing 32 bit values into 64 bit arguments).


Alrighty then,

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20130822/192b559d/attachment.sig>