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