This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |