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

Thomas Orgis thomas-forum at orgis.org
Tue Aug 27 23:33:08 UTC 2013


Am Tue, 27 Aug 2013 23:49:08 +0200
schrieb Reinhard Tartler <siretart at gmail.com>: 

> +if test ".$ac_cv_sizeof_int32_t$ac_cv_sys_file_offset_bits$ac_cv_sizeof_off_t"
> = ".4no8"; then
> +       # Add dual-mode wrapper code.anyways
> +       LFS_LOBJ=lfs_wrap.lo
> +       ac_cv_sys_wide_off_t="yes"
> +       AC_DEFINE(LARGEFILE_WIDE64_OFF_T, 1,
> +       [whether the system is 32bit, but has 64bit off_t])
> +fi

If you detected that situation (the generalist in me would like to see
this without hardcoding 4 and 8 ... and wonders how sizeof(int32_t) !=
4 is possible), I wonder if just defining _FILE_OFFSET_BITS=64 after
adding lfs_wrap.lo wouldn't do the trick. The wrapper macros only
look at that value to define the function names, unless hacked to watch
out for others. I strongly suppose that's where you get multiple
definitions from.

What I only would like to know is if there is some drawback to simply
defining _FILE_OFFSET_BITS=64. I suppose not.

But let me try to get my own logic straight again. With
_FILE_OFFSET_BITS=64, mpg123 build will create _64 functions.
You want aliases without suffix, because of native 64 bit off_t, you
want wrappers with _32 suffix for long arguments.

Current lfs_wrap.c is hardcoded to [no suffix]->_64 with long arguments
on [no suffix]. That is still correct... lfs_alias should work, too,
providing ... just another alias without suffix. Conflicting.
Yeah, you have to untangle that: lfs_wrap needs to define functions
with _32 suffix, mapping to _64. The lfs_alias should work unchanged
(once _FILE_OFFSET_BITS is there) to provide [no_suffix] -> _64.

So, in lfs_wrap.c:

#undef mpg123_tell
/* off_t mpg123_tell(mpg123_handle *mh); */
long attribute_align_arg mpg123_tell(mpg123_handle *mh)

Needs to become

#undef mpg123_tell
/* off_t mpg123_tell(mpg123_handle *mh); */
long attribute_align_arg mpg123_tell_32(mpg123_handle *mh)

in your case. Of course, it's nice when we get to this with macro
automatism, but you could also simply try one brute force patch to
verify that this results in a correct build.


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/20130828/9f4c4f7b/attachment-0001.sig>


More information about the pkg-multimedia-maintainers mailing list