Am Thu, 22 Aug 2013 07:46:55 +0200 schrieb Reinhard Tartler <siret...@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
signature.asc
Description: PGP signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers