[Debian-med-packaging] Bug#949966: libgclib-dev: getLine ABI uses off_t and thus depends on _FILE_OFFSET_BITS

[Andreas Tille]

Control: tags -1 pending

Hi,

I have implemented a solution in Git[1] but want to discuss other options
here.  Latest upstream version seem to need a SONAME bump anyway as far
as I can see.

I wonder what you think how important large file support in gffread might
be for those rarely used architectures.

Kind regards

       Andreas.

On Mon, Jan 27, 2020 at 07:58:25PM +0100, Helmut Grohne wrote:
> Package: libgclib-dev
> Version: 0.11.3-1
> Severity: important
> Tags: ftbfs
> Control: affects -1 + src:gffread
> 
> gffread fails to build from source for 32bit architectures with the
> followin glinker error:
rt DEB_BUILD_MAINT_OPTIONS=future=-lfs
> 
> | /usr/bin/ld: gffread.o: in function `GLineReader::getLine(_IO_FILE*)':
> | /usr/include/gclib/GBase.h:576: undefined reference to `GLineReader::getLine(_IO_FILE*, long long&)'
> 
> The second argument of getLine is actually typed off_t&. libgclib is
> built without _FILE_OFFSET_BITS, so off_t becomes long. gffread is built
> with _FILE_OFFSET_BITS=64, so off_t becomes long long there. In C++,
> these become different overloads and so we get the linker error.
> 
> Fundamentally, I think using off_t in an ABI is difficult. If you do so,
> you must provide both variants. gclib fails to do so.
> 
> As a workaround on the gffread side, unsetting the lfs feature should
> make it build:
> 
> export DEB_BUILD_MAINT_OPTIONS=future=-lfs
> 
> Of course, gffread comes without large file support then. Possibly,
> rebuilding libgclib with _FILE_OFFSET_BITS=64 would be a good solution.
> Beware that doing so is an ABI break and requires an soname bump though.
> 

[1] https://salsa.debian.org/med-team/libgclib/commit/42ec58e895227621d4d4e6a8433d85fb71ac3ccc

-- 
http://fam-tille.de