Bug#913186: ring: FTBFS on 32 bit archs: #error libupnp uses large file support, so users must do that, too

[Uwe Kleine-König]

On Wed, Nov 07, 2018 at 10:24:28PM +0100, Sebastian Ramacher wrote:
> Source: ring
> Version: 20180816.2.e26b79f~ds1-3
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> Tags: sid buster ftbfs
> 
> ring FTBFS on 32 bit architectures:
> | ../../doltlibtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I../..  -I/<<PKGBUILDDIR>>/daemon/src -I/<<PKGBUILDDIR>>/daemon/src/config -I/<<PKGBUILDDIR>>/daemon/src/media -I/<<PKGBUILDDIR>>/daemon/test -I/<<PKGBUILDDIR>>/daemon/src/dring  -DPREFIX=\"/usr\" -DPROGSHAREDIR=\"/usr/share/ring\" -DENABLE_TRACE -DRING_REVISION=\"\" -DRING_DIRTY_REPO=\"dirty\" -DPJSIP_MAX_PKT_LEN=8000 -DPJ_AUTOCONF=1 -Wdate-time -D_FORTIFY_SOURCE=2 -I/<<PKGBUILDDIR>>/daemon/contrib/i686-linux-gnu/include -I/usr/include/jsoncpp -I./ -I../ -DPREFIX=\"/usr\" -DPROGSHAREDIR=\"/usr/share/ring\" -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -DPJ_AUTOCONF=1  -I/<<PKGBUILDDIR>>/daemon/contrib/i686-linux-gnu/include -DNDEBUG=1 -MT libclient_la-datatransfer.lo -MD -MP -MF .deps/libclient_la-datatransfer.Tpo -c -o libclient_la-datatransfer.lo `test -f 'datatransfer.cpp' || echo './'`datatransfer.cpp
> | In file included from /usr/include/upnp/upnp.h:402,
> |                  from /<<PKGBUILDDIR>>/daemon/src/upnp/upnp_context.h:33,
> |                  from configurationmanager.cpp:43:
> | /usr/include/upnp/FileInfo.h:22:2: error: #error libupnp uses large file support, so users must do that, too
> |  #error libupnp uses large file support, so users must do that, too
> |   ^~~~~
> 
> See
> https://buildd.debian.org/status/fetch.php?pkg=ring&arch=i386&ver=20180816.2.e26b79f%7Eds1-3%2Bb2&stamp=1541591693&raw=0
> for a failed build log.

libupnp 1.8 is used here. It is (like libupnp6) compiled with LFS
support since 1.6.11 (and so in the 1.8 branch since 1.8.0). Programs
linking against libupnp must also be compiled using LFS, otherwise
function calls like UpnpVirtualDir_set_SeekCallback and usage of
UpnpFileInfo (which both use off_t whose size if affected by LFS)
results in mismatches. Since libupnp 1.8.3 this mismatch is catched as
can be seen above. Assuming ring really is not compiled with LFS there
might be problems already in earlier versions that were not catched
during buildtime.

Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-voip-maintainers/attachments/20181108/fbadcccf/attachment-0003.sig>