[PATCH] readelf: use fseeko for elf files >= 2 GiB on x86_64-mingw32

[Mike Frysinger]

On 16 Nov 2022 15:19, Brett Werling via Binutils wrote:
> On Wed, Nov 16, 2022 at 11:09 AM Mike Frysinger wrote:
> > On 16 Nov 2022 16:13, Michael Matz wrote:
> > > On Wed, 16 Nov 2022, Mike Frysinger wrote:
> > > > 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.
> > >
> > > No.  I'm claiming that moving to gnulib is work (even if perhaps not
> > > much?) and change and I (personally) don't see the need to invest into
> > > that work and deal with the change.  Had you asked "should I look into
> > > using gnulib in bfd" my answer would have been "well, try it, why not?".
> > > But you asked "should _we_ look" (aka should someone do that), hence my
> > > answer was in the line of "perhaps, but why bother?".
> >
> > you're proposing adding a not insignificant amount of custom portability logic
> > and making the readelf code harder to understand & maintain while also not
> > fixing the same bug in other binutils/ tools.  it is perfectly reasonable to
> > ask you to not add tech debt & make the code base worse off for everyone else
> > to maintain, and instead focus on a common solution that the GNU project is
> > already heavily invested in.  this is, of course, the "GNU Binutils" project.
> 
> I must admit, I'm quite unfamiliar with the history here and my
> original intention
> was to just provide a solution to a specific issue I found with
> readelf. Anything
> beyond that is probably outside the scope of what I'm comfortable addressing.
> If someone else wants to take what I've started here and drive it to completion
> as part of a larger effort, please feel free!
> 
> Also wanted to make sure that my second patch was seen? I think it addresses
> the original concern raised by Jan, but perhaps more is still needed there.

the 2nd patch is what prompted me to follow up to the thread ;).  i grok that
it addresses the specific issue you've found, but it isn't a complete fix, nor
one that improves the codebase for the maintainers to maintain long term.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20221117/9c4f216b/attachment-0001.sig>