| Message ID | 1416468692-4317-1-git-send-email-vapier@gentoo.org |
|---|---|
| State | Superseded, archived |
| Headers | show |
I have no particular opinion about this one change and it's up to Joseph to approve it or not. But it seems quite fragile to tweak individual checks like this to support some arcane configure-sort-of-works case. I don't understand the scenario you are trying to support. I've never heard of doing any step with libc without having a compiler at all. The way I'm familiar with going about bootstrapping is to do just all-gcc and install-gcc first, and then build libc.
On 20 Nov 2014 09:59, Roland McGrath wrote: > I have no particular opinion about this one change and it's up to Joseph to > approve it or not. But it seems quite fragile to tweak individual checks > like this to support some arcane configure-sort-of-works case. I don't > understand the scenario you are trying to support. I've never heard of > doing any step with libc without having a compiler at all. The way I'm > familiar with going about bootstrapping is to do just all-gcc and > install-gcc first, and then build libc. some (many?) targets require some C library headers before they can build for the target at all. we used to do cross-compiling where we'd skip the C library headers, but the amount of patching/hacks we had to add to GCC got unmaintainable, and the code base got more and more hostile to the concept (just search for inhibit_libc). how exactly are you building the first GCC w/out any C library headers ? -mike
> some (many?) targets require some C library headers before they can build > for the target at all. Not to build the compiler itself or other host tools, only to build the target libraries. > how exactly are you building the first GCC w/out any C library headers ? Just 'make all-gcc'. It's only things in the 'all-target-*' makefile targets that need target C library headers. In the beforetime, the long long ago, the build of libgcc was intertwined directly with the compiler build. But for several versions now (all that we support for building libc, I'm pretty sure), it's just a normal target library like all the others (libstdc++ et al) in the build system.
On 20 Nov 2014 10:36, Roland McGrath wrote: > > some (many?) targets require some C library headers before they can build > > for the target at all. > > Not to build the compiler itself or other host tools, only to build the > target libraries. > > > how exactly are you building the first GCC w/out any C library headers ? > > Just 'make all-gcc'. It's only things in the 'all-target-*' makefile > targets that need target C library headers. > > In the beforetime, the long long ago, the build of libgcc was intertwined > directly with the compiler build. But for several versions now (all that > we support for building libc, I'm pretty sure), it's just a normal target > library like all the others (libstdc++ et al) in the build system. it is still integrated ... at least, we attempted exactly that in CrOS with gcc-4.8 and it was not possible to build libgcc & libstdc++ w/out also building the local copy of the compiler. i'm not sure why we're forcing this from the perspective of glibc. being able to install the C library headers for a target should not require probing the assembler/linker/compiler. the installed headers are the same regardless. -mike
On Thu, 20 Nov 2014, Mike Frysinger wrote: > The change to simplify the EABI/OABI check from a tuple to a compile test > broke the ability to bootstrap a cross-compiler when generating the glibc > headers. At that point, there is no compiler yet, so this compile-time > test will always fail. Wrap the error with a basic sanity check so that > if the compiler fails, we assume this setup. I don't see a reason to treat this test any differently from many other configure tests - we expect a working compiler, but may or may not fail configure if the breakage is such that no compiler >= GCC 4.6 should fail the test (in such cases, we don't actually need to have configure tests). The ideal bootstrap procedure we're aiming for is as described at <https://sourceware.org/ml/libc-alpha/2012-03/msg00960.html>. We don't quite have it, but only in that GCC needs reconfiguring and rebuilding for step 5: a basic GCC with static-only libgcc (configured in a way that causes inhibit_libc to be defined) can build glibc, and the resulting glibc is identical to one built after an alternating series of bootstrap GCC and glibc builds, but you need to reconfigure at toplevel to get a GCC that can build and use shared libgcc and other libraries. (And also a glibc build tree built with static-only libgcc may not be able to run the testsuite properly; certainly you need a C++-capable compiler to run some tests.) Nothing in this desired procedure involves configuring glibc without having a compiler for the relevant system. > Note: an alternative might be to just delete the EABI check altogether. > It's not like an OABI compiler will be able to properly build glibc ... If we don't think it's realistic for someone to attempt building with an OABI compiler and get confused by the failure later in the build, that's a possibility. (If anything, failing for non-ARM compilers is a feature - it seems quite plausible for someone to attempt building glibc for a different system without realising they first need to build a cross compiler, or with their configuration wrong in some way so that the cross compiler isn't used.)
> it is still integrated ... at least, we attempted exactly that in CrOS > with gcc-4.8 and it was not possible to build libgcc & libstdc++ w/out > also building the local copy of the compiler. Oh, yes, that's the case. (At least, I also didn't find any way to get it to use a pre-built compiler to build the target libraries, and instead just gave up and let the gratuitous rebuild of the compiler be part of my "build the target libraries" step and I just throw away that second build of the compiler. But I really didn't fight with the GCC makefiles for all that long before I gave up.) But it's not the case that you can't build the compiler without building the target libraries, so it's not the case that you cannot get a compiler with which to build libc. > i'm not sure why we're forcing this from the perspective of glibc. being > able to install the C library headers for a target should not require > probing the assembler/linker/compiler. the installed headers are the > same regardless. That's not necessarily always true, though probably it is in practice and perhaps it should be by policy. That is, nowadays we use compiler-based checks (checking predefines) in some places to contribute to the sysdeps directory selection. It could be that which installed sysdeps headers you get is affected by sysdeps directory choices that were affected by compiler-based configure checks. The only checks of this sort I can think of off hand are for "submodel" sorts of variation, and for x32 (choosing between ABIs in a tri-arch ABI setup); those are cases where we intend the installed headers to be universal across the submodels and across the cooperating ABI sets. But nothing in the infrastructure ensures that there cannot be a case where it matters, and I'm not entirely confident off hand that as a matter of policy we always do or should rule out all such cases. At any rate, I never said anything about "forcing" anything. We do have the install-headers target, after all. What I said is that the notion of using arcane tweaks in individual configure checks to support your use case is too fragile. We've never claimed to, or tried to, support a "no working compiler" configuration before. If we actually want to support that use case, then we should be explicit about it and find a clean and maintainable way to do it. Probably that would be something like an explicit configure switch (that disables the compatible-compiler check, e.g.) and macros we use around all of our compiler-based checks (that make them yield the safest default in the absence of a compiler), but I'm citing the ugliness and unmaintainability of your approach rather than proposing a specific alternative right now. Thanks, Roland
On Thu, 20 Nov 2014, Roland McGrath wrote: > That's not necessarily always true, though probably it is in practice and > perhaps it should be by policy. That is, nowadays we use compiler-based > checks (checking predefines) in some places to contribute to the sysdeps > directory selection. It could be that which installed sysdeps headers you > get is affected by sysdeps directory choices that were affected by > compiler-based configure checks. The only checks of this sort I can think > of off hand are for "submodel" sorts of variation, and for x32 (choosing > between ABIs in a tri-arch ABI setup); those are cases where we intend the > installed headers to be universal across the submodels and across the > cooperating ABI sets. But nothing in the infrastructure ensures that there > cannot be a case where it matters, and I'm not entirely confident off hand > that as a matter of policy we always do or should rule out all such cases. There are some cases where submodel variation does affect the installed headers. At least: * m68k bits/fenv.h and bits/mathinline.h. * sh bits/mathdef.h. (I think these should be fixed.) There are other cases where it may look like submodel variation could affect the headers but actually the variants in different sysdeps directories are identical (e.g. sysdeps/s390/s390-32/bits/wordsize.h and sysdeps/s390/s390-64/bits/wordsize.h - which exist because of the sysdeps directory ordering issue described in <https://sourceware.org/ml/libc-alpha/2014-03/msg00588.html>).
On 20 Nov 2014 20:42, Joseph Myers wrote: > On Thu, 20 Nov 2014, Mike Frysinger wrote: > > The change to simplify the EABI/OABI check from a tuple to a compile test > > broke the ability to bootstrap a cross-compiler when generating the glibc > > headers. At that point, there is no compiler yet, so this compile-time > > test will always fail. Wrap the error with a basic sanity check so that > > if the compiler fails, we assume this setup. > > I don't see a reason to treat this test any differently from many other > configure tests - we expect a working compiler, but may or may not fail > configure if the breakage is such that no compiler >= GCC 4.6 should fail > the test (in such cases, we don't actually need to have configure tests). > > The ideal bootstrap procedure we're aiming for is as described at > <https://sourceware.org/ml/libc-alpha/2012-03/msg00960.html>. We don't > quite have it, but only in that GCC needs reconfiguring and rebuilding for > step 5: a basic GCC with static-only libgcc (configured in a way that > causes inhibit_libc to be defined) can build glibc, and the resulting > glibc is identical to one built after an alternating series of bootstrap > GCC and glibc builds, but you need to reconfigure at toplevel to get a GCC > that can build and use shared libgcc and other libraries. (And also a > glibc build tree built with static-only libgcc may not be able to run the > testsuite properly; certainly you need a C++-capable compiler to run some > tests.) thanks, i'd forgotten about this thread. in Gentoo we support a wide variety of C libraries and versions and compilers, so deviating in overall procedure is a pita (especially since this has largely been working w/gcc-3.x+). i know that's not really glibc's problem since the project only concerns itself with the future. just stating it to vent a bit :p. > > Note: an alternative might be to just delete the EABI check altogether. > > It's not like an OABI compiler will be able to properly build glibc ... > > If we don't think it's realistic for someone to attempt building with an > OABI compiler and get confused by the failure later in the build, that's a > possibility. see below > (If anything, failing for non-ARM compilers is a feature - it seems quite > plausible for someone to attempt building glibc for a different system > without realising they first need to build a cross compiler, or with their > configuration wrong in some way so that the cross compiler isn't used.) i don't see why arm should be special in this regard. none of the other targets do this. if you configure for a target and you don't have a compiler that can produce for that, you'll get lots of errors. if this is a use case we think is useful (i don't think it is), we probably should have it be done for everyone and not ad-hoc for arm. -mike
On 20 Nov 2014 12:54, Roland McGrath wrote: > > it is still integrated ... at least, we attempted exactly that in CrOS > > with gcc-4.8 and it was not possible to build libgcc & libstdc++ w/out > > also building the local copy of the compiler. > > Oh, yes, that's the case. (At least, I also didn't find any way to get it > to use a pre-built compiler to build the target libraries, and instead just > gave up and let the gratuitous rebuild of the compiler be part of my "build > the target libraries" step and I just throw away that second build of the > compiler. But I really didn't fight with the GCC makefiles for all that > long before I gave up.) But it's not the case that you can't build the > compiler without building the target libraries, so it's not the case that > you cannot get a compiler with which to build libc. so from glibc's perspective, "not our problem" ;) > > i'm not sure why we're forcing this from the perspective of glibc. being > > able to install the C library headers for a target should not require > > probing the assembler/linker/compiler. the installed headers are the > > same regardless. > > That's not necessarily always true, though probably it is in practice and > perhaps it should be by policy. That is, nowadays we use compiler-based > checks (checking predefines) in some places to contribute to the sysdeps > directory selection. It could be that which installed sysdeps headers you > get is affected by sysdeps directory choices that were affected by > compiler-based configure checks. The only checks of this sort I can think > of off hand are for "submodel" sorts of variation, and for x32 (choosing > between ABIs in a tri-arch ABI setup); those are cases where we intend the > installed headers to be universal across the submodels and across the > cooperating ABI sets. But nothing in the infrastructure ensures that there > cannot be a case where it matters, and I'm not entirely confident off hand > that as a matter of policy we always do or should rule out all such cases. true, the sysdeps angle throws a bit of a wrench in there. we're inconsistent though as to how we probe. some check CPP defines, some check the tuple, some check compiler flags, or a combination thereof. > At any rate, I never said anything about "forcing" anything. We do have > the install-headers target, after all. What I said is that the notion of > using arcane tweaks in individual configure checks to support your use case > is too fragile. We've never claimed to, or tried to, support a "no working > compiler" configuration before. If we actually want to support that use > case, then we should be explicit about it and find a clean and maintainable > way to do it. Probably that would be something like an explicit configure > switch (that disables the compatible-compiler check, e.g.) and macros we > use around all of our compiler-based checks (that make them yield the > safest default in the absence of a compiler), but I'm citing the ugliness > and unmaintainability of your approach rather than proposing a specific > alternative right now. i certainly cannot disagree with the specific fragiliness of my proposed change. the difference with this check compared to just about every other one is that it lacks a cache var wrapping as well as fallback logic. the pattern seen in the codebase is largely: AC_CACHE_CHECK(blah blah, libc_cv_foo, [ [...do the compile/whatever test...], [], [libc_cv_foo=yes], [libc_cv_foo=no]]) if there is an error triggering, it's after the cache var has been loaded, so we can force the knob in the right direction. the change in this file was done under the heading of simplification where the supposition is that checking CPP defines is more reliable than the target tuple. but if binutils & gcc (and glibc in some places) hard require the form of the tuple in order to get certain behavior, why should we be different ? checking the tuple for *-gnueabi is certainly faster than compiling code :). i would like to see an option like "only install headers", but it would mean trusting the information encoded in the tuple which the commit here specifically moved away from. -mike
On Thu, 20 Nov 2014, Mike Frysinger wrote: > i would like to see an option like "only install headers", but it would mean > trusting the information encoded in the tuple which the commit here specifically > moved away from. In general I think we should trust tuples *less* - it should be possible to configure glibc with the same tuple as used for GCC (so, for example, i686-*-linux-gnu and x86_64-*-linux-gnu should both work for building both 32-bit and 64-bit glibc - much like for MIPS we examine the value of _MIPS_SIM to determine the ABI being built for). (I also think all cases that can use the same tuple with GCC should install the same headers.)
> so from glibc's perspective, "not our problem" ;) That was also so. What I pointed out is that it's also only a problem for you because you decided it was. You can instead just decide not to care about the gratuitous rebuild of the compiler. > i certainly cannot disagree with the specific fragiliness of my proposed > change. the difference with this check compared to just about every > other one is that it lacks a cache var wrapping as well as fallback > logic. I'd certainly have no objection to a change to wrap AC_CACHE_CHECK around it. > the change in this file was done under the heading of simplification > where the supposition is that checking CPP defines is more reliable than > the target tuple. It is so in the sense of long-term maintainability. If what we care about is how the compiler is behaving, then checking the compiler keeps it proximate rather than one or (many) more steps removed from where the actual decision is made. The exact meanings of tuples change over time, and some packages are more sensitive than others to the exact tuple. > but if binutils & gcc (and glibc in some places) hard require the form of > the tuple in order to get certain behavior, why should we be different ? > checking the tuple for *-gnueabi is certainly faster than compiling code > :). binutils has no other target-specific prerequisite to go on. GCC has none but binutils.
On 20 Nov 2014 21:35, Joseph Myers wrote: > On Thu, 20 Nov 2014, Mike Frysinger wrote: > > i would like to see an option like "only install headers", but it would mean > > trusting the information encoded in the tuple which the commit here specifically > > moved away from. > > In general I think we should trust tuples *less* - it should be possible > to configure glibc with the same tuple as used for GCC (so, for example, > i686-*-linux-gnu and x86_64-*-linux-gnu should both work for building both > 32-bit and 64-bit glibc - much like for MIPS we examine the value of > _MIPS_SIM to determine the ABI being built for). (I also think all cases > that can use the same tuple with GCC should install the same headers.) i'm aware you can do multilib, but you'd still have to configure glibc with the right tuple in order for it to behave correctly. this is how every autotool package works and i'm not sure how making glibc special here is useful. i'm not sure it's even feasible unless we avoid autotools entirely. e.g. ./configure --host=i686-pc-linux-gnu CC="x86_64-pc-linux-gnu-gcc -m32" -mike
Mike Frysinger <vapier@gentoo.org> writes: > i'm aware you can do multilib, but you'd still have to configure glibc with the > right tuple in order for it to behave correctly. this is how every autotool > package works and i'm not sure how making glibc special here is useful. i'm not > sure it's even feasible unless we avoid autotools entirely. The gcc target libraries are configured using the same tuple for all multilibs. But they need to be aware of this situation. Andreas.
diff --git a/sysdeps/arm/preconfigure b/sysdeps/arm/preconfigure index 59d776d..6a4c84e 100644 --- a/sysdeps/arm/preconfigure +++ b/sysdeps/arm/preconfigure @@ -7,9 +7,13 @@ arm*) cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ +/* Do not abort when bootstrapping initial glibc headers -- determine that with + a basic sanity check. */ +#ifdef __arm__ #if !__ARM_EABI__ #error #endif +#endif int main () { diff --git a/sysdeps/arm/preconfigure.ac b/sysdeps/arm/preconfigure.ac index d78817b..157e822 100644 --- a/sysdeps/arm/preconfigure.ac +++ b/sysdeps/arm/preconfigure.ac @@ -4,8 +4,12 @@ GLIBC_PROVIDES dnl See aclocal.m4 in the top level source directory. case "$machine" in arm*) AC_TRY_COMPILE([ +/* Do not abort when bootstrapping initial glibc headers -- determine that with + a basic sanity check. */ +#ifdef __arm__ #if !__ARM_EABI__ #error +#endif #endif], [], [], [AC_MSG_ERROR([Old ABI no longer supported])]) # If the compiler enables unwind tables by default, this causes
The change to simplify the EABI/OABI check from a tuple to a compile test broke the ability to bootstrap a cross-compiler when generating the glibc headers. At that point, there is no compiler yet, so this compile-time test will always fail. Wrap the error with a basic sanity check so that if the compiler fails, we assume this setup. Signed-off-by: Mike Frysinger <vapier@gentoo.org> --- Note: an alternative might be to just delete the EABI check altogether. It's not like an OABI compiler will be able to properly build glibc ... sysdeps/arm/preconfigure | 4 ++++ sysdeps/arm/preconfigure.ac | 4 ++++ 2 files changed, 8 insertions(+)