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 indeed works and fixes the FTBFS. However it seems that, at least
for some of the issues, it just hides them. For instance the wrong type
for timeval.tv_usec, reported by Simon upstream [1], was detected by the
conformance tests. Quoting utmpx.h/conform.out:
| /tmp/tmp98wzaavx/test.c:4:35: error: conflicting types for ‘b2_10’; have
‘__suseconds64_t’ {aka ‘long long int’}
| 4 | extern __typeof__ (a2_10.tv_usec) b2_10;
| | ^~~~~
| /tmp/tmp98wzaavx/test.c:3:20: note: previous declaration of ‘b2_10’ with type
‘suseconds_t’ {aka ‘long int’}
| 3 | extern suseconds_t b2_10;
| | ^~~~~
| FAIL: Type of member tv_usec
And we know it is the reason for the FTBFS of libflorist [2], so should
we just ignore that issue anyway?
Regards
Aurelien
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=31510
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067223
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
