Hi again James,
this is a kind ping since as I wrote below the issue seems not be solved.
Kind regards
Andreas.
On Thu, Sep 28, 2017 at 04:24:19PM +0200, Andreas Tille wrote:
> Hi James,
>
> I uploaded staden-io-lib now with your patch which solved the other bug.
>
> On Thu, Sep 28, 2017 at 10:11:50AM +0100, James Bonfield wrote:
> > > On Tue, Sep 26, 2017 at 10:38:12PM +0200, Christian Seiler wrote:
> >
> > Debugging the code for this test case shows it is doing fseeko with
> > offset 8 (on a working machine), SEEK_SET. Strace shows this as an
> > lseek SEEK_SET to offset 0 and a read of 8 for some reason, but it
> > amounts to the same thing.
> >
> > I'll try and find a qemu / virtual machine of one of the affected
> > architectures to test on.
> >
> > My money is on something odd to do with large file support (it's a
> > total minefield) and changing of types. Eg bad prototypes leading to
> > 32-bit to 64-bit type changes yielding a daft interpretation of offset
> > and/or whence.
> >
> > I see bgzip.c doesn't have the standard boilerplate header setup of:
> >
> > #ifdef HAVE_CONFIG_H
> > #include "io_lib_config.h"
> > #endif
> >
> > Does adding that fix the fseeko call to start working again?
>
> Unfortunately not - see here the build logs:
>
> https://buildd.debian.org/status/package.php?p=staden-io-lib
>
> Thanks for your quick response in any case
>
> Andreas.
--
http://fam-tille.de
