Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Luis Machado <luis.machado@arm.com>]

On 8/9/22 16:49, Paul Eggert wrote:
> On 8/8/22 11:01, Luis Machado wrote:
>> BFD is left in the dark about the 64-bit time_t support for 32-bit hosts.
> 
> OK, but how about if we fix that by syncing non-Gnulib-using code with Gnulib-using code? This should be relatively easy. Something like the first attached patch, say. If there's still interest in 32-bit binutils this would be a better approach. (If there's not, then we don't have to install any patch. :-)

Sure, but that would make BFD use gnulib, which I don't think is desirable. I don't know why binutils has chosen not to use gnulib, but I'm assuming
the binutils community wouldn't like to pull gnulib code into it without discussing it first. My fix only disables gnulib's use of 64-bit time_t.

Nick, would you know the reason behind binutils not using gnulib?

> 
> PS. While looking into this I noticed a grep portability bug in a couple of 'configure.ac's, fixed in the 2nd attached patch.
> 

Thanks!

> PPS. I couldn't get a 32-bit version of binutils-gdb to build on Fedora x86-64, even without either of the attached patches. See the 3rd attached file, which is a compressed log of my attempt to build. Here's the first part of the failing output:
> 
>    /bin/sh ../libtool  --tag=CXX   --mode=link gcc -m32 -Wall -pthread -Wno-switch -g -O2       -o gp-archive gp-archive.o ArchiveExp.o libgprofng.la  -L../../zlib -lz
>    libtool: link: gcc -m32 -Wall -pthread -Wno-switch -g -O2 -o gp-archive gp-archive.o ArchiveExp.o  ./.libs/libgprofng.a -L/home/eggert/src/gnu/build/zlib -L/home/eggert/src/gnu/build/libiberty /home/eggert/src/gnu/build/opcodes/.libs/libopcodes.a /home/eggert/src/gnu/build/bfd/.libs/libbfd.a -liberty -lpthread -ldl -lz -pthread
>    /usr/bin/ld: gp-archive.o: in function `er_archive::check_args(int, char**)':
> 
> /home/eggert/src/gnu/build/gprofng/src/../../../binutils-gdb/gprofng/src/gp-archive.cc:573: undefined reference to `operator new(unsigned int)'

Some of the sub-projects within binutils-gdb are C++ now, so it seems this is attempting to build them with a C compiler.