bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problematic redefinition of 'stat' and 'fstat'


From: Eli Zaretskii
Subject: Re: Problematic redefinition of 'stat' and 'fstat'
Date: Wed, 25 Dec 2019 05:34:56 +0200

> From: Bruno Haible <address@hidden>
> Cc: Eli Zaretskii <address@hidden>
> Date: Tue, 24 Dec 2019 22:42:06 +0100
> 
> > Which is exactly what happened to me
> > while building the latest versions of GDB, which uses Gnulib, but
> > links against the BFD library, which doesn't.
> 
> The BFD library should move to using 'large files' as soon as possible,
> IMO. You don't want BFD to reject a .a file just because it's larger
> than 2 GiB. You don't want BFD to report that a .a file is empty just
> because it happens to be exactly 4 GiB in size.

BFD is just one example of potential problems, of course.  So even if
BFD does what you suggest, the more general problem will remain.

> > Why is this redefinition forced on programs that use Gnulib on
> > Windows?
> 
> Gnulib does not force it. You can invoke gnulib-tool with option
> '--avoid=largefile'; then it will not force support for large files
> onto the package. But for the case of BFD and GDB, I would not
> recommend that.

Gnulib's configuration for GDB is determined by requirements of many
platforms.  It is unlikely that the configuration will be changed due
to issues with relatively unimportant platform such as MinGW.

> > IOW, it sounds like this redefinition is not needed where it works,
> > and cannot be used safely where it doesn't work.
> 
> Mingw defines 'struct stat' also differently when the macro
> _USE_32BIT_TIME_T is defined.

Since MinGW64 dropped support of Windows XP, _USE_32BIT_TIME_T is just
old cruft that has no practical importance anymore for MinGW64
development.

Anyway, I guess my request is rejected, and I will have to hack Gnulib
by hand in each project I'll need to compile.  Thank you for your
time.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]