From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8669 invoked by alias); 20 Nov 2014 21:27:20 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 8657 invoked by uid 89); 20 Nov 2014 21:27:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org Date: Thu, 20 Nov 2014 21:27:00 -0000 From: Mike Frysinger To: Roland McGrath Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] arm: do not abort EABI check for bootstrapping Message-ID: <20141120212715.GF3743@vapier.wh0rd.info> Mail-Followup-To: Roland McGrath , libc-alpha@sourceware.org References: <1416468692-4317-1-git-send-email-vapier@gentoo.org> <20141120175902.426FF2C3B2F@topped-with-meat.com> <20141120181950.GB3743@vapier.wh0rd.info> <20141120183654.DC12D2C3B2F@topped-with-meat.com> <20141120200805.GC3743@vapier.wh0rd.info> <20141120205438.9D3A22C3B2C@topped-with-meat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="juZjCTNxrMaZdGZC" Content-Disposition: inline In-Reply-To: <20141120205438.9D3A22C3B2C@topped-with-meat.com> X-SW-Source: 2014-11/txt/msg00565.txt.bz2 --juZjCTNxrMaZdGZC Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 4287 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. >=20 > 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 ju= st > gave up and let the gratuitous rebuild of the compiler be part of my "bui= ld > 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. bei= ng > > 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. >=20 > 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 the= re > 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 inconsist= ent=20 though as to how we probe. some check CPP defines, some check the tuple, s= ome=20 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 ca= se > is too fragile. We've never claimed to, or tried to, support a "no worki= ng > compiler" configuration before. If we actually want to support that use > case, then we should be explicit about it and find a clean and maintainab= le > 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 ch= ange.=20=20 the difference with this check compared to just about every other one is th= at it=20 lacks a cache var wrapping as well as fallback logic. the pattern seen in = the=20 codebase is largely: AC_CACHE_CHECK(blah blah, libc_cv_foo, [ [...do the compile/whatever test...], [], [libc_cv_foo=3Dyes], [libc_cv_foo=3Dno]]) if there is an error triggering, it's after the cache var has been loaded, = so we=20 can force the knob in the right direction. the change in this file was done under the heading of simplification where = the=20 supposition is that checking CPP defines is more reliable than the target t= uple.=20=20 but if binutils & gcc (and glibc in some places) hard require the form of t= he=20 tuple in order to get certain behavior, why should we be different ? check= ing=20 the tuple for *-gnueabi is certainly faster than compiling code :). i would like to see an option like "only install headers", but it would mea= n=20 trusting the information encoded in the tuple which the commit here specifi= cally=20 moved away from. -mike --juZjCTNxrMaZdGZC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUblyzAAoJEEFjO5/oN/WB1TcP/1KJm4JE4U7iBYE7ieRVsZZx U4P1dYwqINPppK4Eq7yoaUV2k2GJcMtfO2+rFnChiRD/BJzTS7me9RNjiy2CtbvM 1Gf1AXQpzJO5lm848MwKTBMItYOypOwES8UqkKO7yjEAUC5n7wqltl6gvzcyZ+3d ClcDUommwFdaiZ73XgfXpS8HaHoIbf9Xd39XW/Joq6jDyHnUa/tFFYDJ9tkkg+S6 XOVRb6Jz8g0eozp+G/nfFC2kkGfLfybkVz/VOvKfDri9L5raOsivJpy4iVkO0k50 dpU+fgHW5SS2hHLBEica7V0jZGKqSCfJ0xxN/GM4KzcSIYseapbVm14thm+fJ2c4 Y7ykO5sU9nTZdN3tMnKEhSD5OOWizTpjs2YOMlOkNcuuHTmT2tbJ+M0pI0bjTACO GFcJE744hFTgME/TR9BtcR6UbDdwxNszdiFL58Xl2S62hJ6w8S9xwtS0BKTf9qmD Gc7IILvLzbsRhwFE6EhhT+EM6epqL5JNj0rC6TjAd9bkYQ5fivIwom/fH6RosiUT 78oLAuXR95vE521iLu5XZv29AL7HICoBFHjFz7Z43RojDyojoW3zg/kM7KvN2m3n YLucPA++SpRO4LA3ANTahdAYumMFPRHgD8AHFdCRI9VGQpYtexf2/sWTJ3yRqDfi CSnn+UvQjZLyYIhXTEZn =ed0e -----END PGP SIGNATURE----- --juZjCTNxrMaZdGZC--