Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t
Hi Helmut,
On 2024-04-08 22:19, Helmut Grohne wrote:
> Control: tags -1 + patch
>
> Hi Aurelien and Canonical folks,
>
> On Tue, Apr 02, 2024 at 08:53:31PM +0200, Aurelien Jarno wrote:
> > Starting with gcc-12 version 12.3.0-15, -D_TIME_BITS=64 together with
> > -D_FILE_OFFSET_BITS=64 are passed by default on 32-bit architectures
> > except i386.
> >
> > This has been partially fixed in the 2.37-15.1 NMU by adding
> > -U_TIME_BITS to CFLAGS, however it causes failures in the testsuite:
>
> There are two subtleties about -U_TIME_BITS in a moment.
>
> > | +-+
> > | | Encountered regressions that don't match expected failures. |
> > | +-+
> > | FAIL: conform/ISO/stdio.h/linknamespace
>
> The detail for this failure is:
>
> | [initial] fgetpos64
> | [initial] fopen64
> | [initial] freopen64
> | [initial] fsetpos64
>| [initial] tmpfine64
>
> What linknamespace.py wants to tell us here is that it expected
> fgetpos64, but no fgetpos64 was declared. It was not declared, because
> there is no difference between fgetpos and fgetpos64 after defining
> -D_FILE_OFFSET_BITS=64 (which is also in the default compiler flags).
>
> The other failures are of very similar kind, but there also is another
> kind.
>
> > | FAIL: conform/POSIX/sys/stat.h/conform
>
> The detail for this failure contains:
>
> | /tmp/tmpnzda_r9j/test.c:90:35: error: conflicting types for 'b2_8'; have
> '__time64_t' {aka 'long long int'}
> |90 | extern __typeof__ (a2_8.st_atime) b2_8;
> | | ^~~~
> | /tmp/tmpnzda_r9j/test.c:89:17: note: previous declaration of 'b2_8' with
> type '__time_t' {aka 'long int'}
> |89 | extern __time_t b2_8;
> | | ^~~~
>
> Here, it tells us that it expected the st_atime field of struct stat to
> have type __time_t (the 32 bit one), but it really has __time64_t.
>
> Looking at the invocation of linknamespace.py you can see:
>
> | python3 -B linknamespace.py --cc='arm-linux-gnueabihf-gcc-12'
> --flags='-I../include
> -I/build/reproducible-path/glibc-2.37/build-tree/armhf-libc
> -I../sysdeps/unix/sysv/linux/arm/le -I../sysdeps/unix/sysv/linux/arm
> -I../sysdeps/arm/nptl -I../sysdeps/unix/sysv/linux/include
> -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread
> -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
> -I../sysdeps/unix/arm -I../sysdeps/unix -I../sysdeps/posix
> -I../sysdeps/arm/le/armv7/multiarch -I../sysdeps/arm/armv7/multiarch
> -I../sysdeps/arm/le/armv7 -I../sysdeps/arm/armv7 -I../sysdeps/arm/armv6t2
> -I../sysdeps/arm/armv6 -I../sysdeps/arm/le -I../sysdeps/arm/include
> -I../sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32
> -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic
> -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabihf/12/include -isystem
> /build/reproducible-path/glibc-2.37/debian/include -I..' ...
>
> In particular, what you do not see is -U_TIME_BITS inside --flags.
>
> > Ubuntu has just ignored those failures for now, but I am just afraid
> > that if we do the same, nobody will fix them.
>
> Armed with this knowledge, I think we need two changes. For one thing
> debian/sysdeps/linux.mk needs to add -U_FILE_OFFSET_BITS to extra_cflags
> to revert any possible ABI changing effects. For another, the
> conformance tests use independent compiler flags defined in
> conform/Makefile. There, a naive patch seems to be:
>
> -conformtest-cc-flags = -I../include $(+sysdep-includes) $(sysincludes) -I..
> +conformtest-cc-flags = -U_FILE_OFFSET_BITS -U_TIME_BITS -I../include
> $(+sysdep-includes) $(sysincludes) -I..
>
> With these two changes, I am able to successfully build glibc on armhf
> with the conformance test suite passing.
>
> > In addition it means that upstream glibc does not build anymore by
> > default on a 32-bit Debian. Not really a Debian issue, but that is not
> > nice either and should probably be fixed.
>
> I think that latter change may be applicable upstream. Running the
> conformance test suite with either _FILE_OFFSET_BITS or _TIME_BITS set
> is not expected nor supported. This is partially evident from
> conform/linknamespace.py in a comment:
>
> | # * Header inclusions should be compiled several times with
> | # different options such as -O2, -D_FORTIFY_SOURCE and
> | # -D_FILE_OFFSET_BITS=64 to find out what symbols are undefined
> | # from such a compilation; this is not yet implemented.
>
> The conformance test suite clearly wants to manage these macros (and its
> effects on symbols) explicitly and does not expect them to be
> pre-defined.
Thanks for you analysis and your patch. In short your proposal is to
extend the initial patch from Steve to fully hide the fact that the
compiler default to -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64.
This
Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t
Control: tags -1 + patch
Hi Aurelien and Canonical folks,
On Tue, Apr 02, 2024 at 08:53:31PM +0200, Aurelien Jarno wrote:
> Starting with gcc-12 version 12.3.0-15, -D_TIME_BITS=64 together with
> -D_FILE_OFFSET_BITS=64 are passed by default on 32-bit architectures
> except i386.
>
> This has been partially fixed in the 2.37-15.1 NMU by adding
> -U_TIME_BITS to CFLAGS, however it causes failures in the testsuite:
There are two subtleties about -U_TIME_BITS in a moment.
> | +-+
> | | Encountered regressions that don't match expected failures. |
> | +-+
> | FAIL: conform/ISO/stdio.h/linknamespace
The detail for this failure is:
| [initial] fgetpos64
| [initial] fopen64
| [initial] freopen64
| [initial] fsetpos64
| [initial] tmpfile64
What linknamespace.py wants to tell us here is that it expected
fgetpos64, but no fgetpos64 was declared. It was not declared, because
there is no difference between fgetpos and fgetpos64 after defining
-D_FILE_OFFSET_BITS=64 (which is also in the default compiler flags).
The other failures are of very similar kind, but there also is another
kind.
> | FAIL: conform/POSIX/sys/stat.h/conform
The detail for this failure contains:
| /tmp/tmpnzda_r9j/test.c:90:35: error: conflicting types for 'b2_8'; have
'__time64_t' {aka 'long long int'}
|90 | extern __typeof__ (a2_8.st_atime) b2_8;
| | ^~~~
| /tmp/tmpnzda_r9j/test.c:89:17: note: previous declaration of 'b2_8' with type
'__time_t' {aka 'long int'}
|89 | extern __time_t b2_8;
| | ^~~~
Here, it tells us that it expected the st_atime field of struct stat to
have type __time_t (the 32 bit one), but it really has __time64_t.
Looking at the invocation of linknamespace.py you can see:
| python3 -B linknamespace.py --cc='arm-linux-gnueabihf-gcc-12'
--flags='-I../include
-I/build/reproducible-path/glibc-2.37/build-tree/armhf-libc
-I../sysdeps/unix/sysv/linux/arm/le -I../sysdeps/unix/sysv/linux/arm
-I../sysdeps/arm/nptl -I../sysdeps/unix/sysv/linux/include
-I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread
-I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix/arm -I../sysdeps/unix -I../sysdeps/posix
-I../sysdeps/arm/le/armv7/multiarch -I../sysdeps/arm/armv7/multiarch
-I../sysdeps/arm/le/armv7 -I../sysdeps/arm/armv7 -I../sysdeps/arm/armv6t2
-I../sysdeps/arm/armv6 -I../sysdeps/arm/le -I../sysdeps/arm/include
-I../sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic
-nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabihf/12/include -isystem
/build/reproducible-path/glibc-2.37/debian/include -I..' ...
In particular, what you do not see is -U_TIME_BITS inside --flags.
> Ubuntu has just ignored those failures for now, but I am just afraid
> that if we do the same, nobody will fix them.
Armed with this knowledge, I think we need two changes. For one thing
debian/sysdeps/linux.mk needs to add -U_FILE_OFFSET_BITS to extra_cflags
to revert any possible ABI changing effects. For another, the
conformance tests use independent compiler flags defined in
conform/Makefile. There, a naive patch seems to be:
-conformtest-cc-flags = -I../include $(+sysdep-includes) $(sysincludes) -I..
+conformtest-cc-flags = -U_FILE_OFFSET_BITS -U_TIME_BITS -I../include
$(+sysdep-includes) $(sysincludes) -I..
With these two changes, I am able to successfully build glibc on armhf
with the conformance test suite passing.
> In addition it means that upstream glibc does not build anymore by
> default on a 32-bit Debian. Not really a Debian issue, but that is not
> nice either and should probably be fixed.
I think that latter change may be applicable upstream. Running the
conformance test suite with either _FILE_OFFSET_BITS or _TIME_BITS set
is not expected nor supported. This is partially evident from
conform/linknamespace.py in a comment:
| # * Header inclusions should be compiled several times with
| # different options such as -O2, -D_FORTIFY_SOURCE and
| # -D_FILE_OFFSET_BITS=64 to find out what symbols are undefined
| # from such a compilation; this is not yet implemented.
The conformance test suite clearly wants to manage these macros (and its
effects on symbols) explicitly and does not expect them to be
pre-defined.
Hope this helps
Helmut
Processed: Re: Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t
Processing control commands: > tags -1 + patch Bug #1068251 [src:glibc] glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t Added tag(s) patch. -- 1068251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068251 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
