Hi Jeff, Thanks for looking at my patch.
On Sun, Dec 01, 2024 at 02:40:47PM -0700, Jeff Law wrote: > On 4/30/24 12:45 PM, Helmut Grohne wrote: > > The definition of LIMITS_H_TEST evaluates its existence in > > BUILD_SYSTEM_HEADER_DIR, but we'd actually need it to check a target > > version. Hence this check occasionally produces misdetections when build > > and target differ. In some cases such as cygming, the header is only > > installed after performing the build. Instead of resolving these > > situations by guessing, defer the test to the time of use and check for > > the header using __has_include_next which will use the correct include > > search path. > > > > 2024-04-30 Helmut Grohne <hel...@subdivi.de> > > > > PR bootstrap/80677 > > * gcc/limitx.h: Only #include syslimits.h when another <limits.h> > > exists. > > * gcc/limity.h: Only #include limits.h when another <limits.h> > > exists. > > * gcc/Makefile.in: Delete LIMITS_H_TEST default and always wrap > > limits.h with limitx.h and limity.h. > > * Makefile.tpl: Drop forwarding of LIMITS_H_TEST > > * Makefile.in: Regenerate. > > * gcc/config/i386/t-cygming: Delete unused LIMITS_H_TEST. > > * gcc/config/t-rtems: Likewise. > > * gcc/config/t-vxworks: Likewise. > > * gcc/config/vms/t-vms: Likewise. > As I noted in the related BZ. I think there's something more fundamental > going on here. The claim that this stuff doesn't work for host != target > isn't as general as one might think as we do those kind of builds every day. I agree that the failure is uncommon, but that doesn't make it any less wrong. There are two ways in which this test can fail. 1. It detects presence of limits.h when it really is absent. 2. It detects absence of limits.h when it really is present. We see that the test is overridden for rtems, vxworks and vms, hinting that such misdetections (both forms) actually occur in practice. To understand what happens when, we need to consider a few different configurations. When cross building a compiler, BUILD_SYSTEM_HEADER_DIR becomes CROSS_SYSTEM_HEADER_DIR and things tend to work. In case of a non-canadian cross toolchain build, it depends on whether a sysroot is provided. When it is, CROSS_SYSTEM_HEADER_DIR is being used and again things tend to work. The interesting case is a building a non-canadian cross toolchain without a sysroot. Essentially in order to build such a toolchain, you must separate the headers for different architectures in to different, architecture-dependent prefixes. That's precisely what Debian's multiarch is. I'm not sure who else but Debian builds cross toolchains without a sysroot. > I would start by first getting the debian multiarch patches upstreamed as I > get a sense this is related to multiarch. As a result, your hint a multiarch indeed is relevant here. Still what happens in that case is that the cross toolchain build looks into $(BUILD_SYSTEM_HEADER_DIR)/limits.h (which happens to be $(NATIVE_SYSTEM_HEADER_DIR)/limits.h) to figure out whether the target architecture has a limits.h. As much as you try to twist this around, it quite simply is and remains wrong. It just happens that everyone else does have a limits.h whenever their cross toolchain expects one there or uses a sysroot, in which case the lookup is redirected to CROSS_SYSTEM_HEADER_DIR and does something reasonable. There is a secondary failure going on here. It is the expectation that your libc installs limits.h directly into *_SYSTEM_HEADER_DIR. While that is the case in almost all situations (even on Debian presently), I am in the process of changing this and intend to move limits.h to a multiarch location, because surprisingly glibc's limits.h is different from musl's limits.h and as a result, we cannot install them into the same place /usr/include/limits.h. So your libc may provide limits.h on the compiler's default search path in a directory that happens not to be *_SYSTEM_HEADER_DIR. When that happens, LIMITS_H_TEST will detect absence and we have a false negative detection. As a result, fixing LIMITS_H_TEST becomes a prerequisite for upstreaming the multiarch patches. I also am of the opinion that upstreaming multiarch into gcc would be good as I had to rebase those patches more than once. Those patches predate my involvement and I do not understand why they have been rejected earlier. Given how difficult it is to get even the most simple patches (e.g. fixing an ICE in __has_include_next) into gcc. I do not dare to drive this process without a mentor. In case someone else wants, I offer my support with the Debian side. But then, we very much need this patch first, so that's kind a a chicken&egg problem now. Helmut
