On 16 Nov 2022 14:44, Michael Matz wrote:
> On Wed, 16 Nov 2022, Mike Frysinger via Binutils wrote:
> > > >>> I think you are correct, this will need some conditional logic to be "safe"
> > > >>> to
> > > >>> include, and even then the casting to off_t would become a little more
> > > >>> complicated. I will look deeper into what can be done here.
> > > >>
> > > >> See bfd/bfdio.c and bfd/configure.ac
> > > > 
> > > > should we look at bfd using gnulib ?
> 
> The patch is for readelf, which doesn't use libbfd.

i'm aware.  my original message called this difference out.  using gnulib
in libbfd seems dicey when statically linking is common, and gnulib does
not provide symbol isolation, which means we'd see a lot of bleeding.

> (And if readelf 
> should use gnulib for this?  I don't know, seems overkill for a single 
> function).
> 
> > > > growing our own portability layer sounds
> > > > like a lot of dupicative effort ...
> 
> I think "growing" and "lot of" don't describe the effort.  Rewriting to 
> use gnulib (and the corresponding necessary testing) might be trivial as 
> well (though I don't think so), but the returns are still very small.

i disagree with your assessment.  the patch proposed isn't exactly trivial,
nor is it widely tested like gnulib.

further, if you read the existing binutils/configure.ac, there's a lot of
"copied from gnulib" logic in there that would get cleaned up.  there's
also logic for old systems that i doubt aren't actively tested (e.g. who
is actually building on Next 3.2?).

even further, readelf isn't the only file under binutils/ that uses fseek,
but it seems to be the only program you're trying to fix.  so the others
are still broken, which wouldn't be the case if gnulib was used.

even even further, gnulib is already in the tree.  it isn't like you have
to import & integrate its build logic or manage its autotool logic or its
header paths.  there are 3 top-level projects using it now, one of which
i converted, and it was pretty trivial.

> > realistically, is anyone actually testing those old distros ?
> 
> Depends on the definition of old.  For instance our oldish enterprise 
> stuff (SLES12) still has current binutils, so at least there it's tested 
> relatively good.  OTOH it's only 9 years old, so some might say that 
> doesn't qualify :)

assuming it shipped with a glibc version that supported POSIX 1003.1 (2013
edition), no, i don't consider that to be that old.  it's got all the fun
*at APIs and such.  i don't recall what the 2016 edition introduced, and i
don't think there are easy summaries to find, but i doubt much of it would
be relevant for binutils/.

are you claiming that current gnulib versions can't support even those old
versions of glibc ?  i'd find that extremely surprising, and really sounds
like a bug that should be taken up with the gnulib folks.
-mike