From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 318C33857C70 for ; Mon, 8 Nov 2021 18:14:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 318C33857C70 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Received: by smtp.gentoo.org (Postfix, from userid 559) id EC934342E86; Mon, 8 Nov 2021 18:14:14 +0000 (UTC) Date: Mon, 8 Nov 2021 13:14:16 -0500 From: Mike Frysinger To: newlib@sourceware.org Subject: Re: what's up with _COMPILING_NEWLIB Message-ID: Mail-Followup-To: newlib@sourceware.org References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="q2kYuhCYFibSzVRe" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 18:14:19 -0000 --q2kYuhCYFibSzVRe Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 08 Nov 2021 16:05, Corinna Vinschen wrote: > On Nov 8 06:46, Mike Frysinger wrote: > > On 08 Nov 2021 11:05, Corinna Vinschen wrote: > > > On Nov 6 20:21, Mike Frysinger wrote: > > > > i stumbled across _COMPILING_NEWLIB and it seems to be what i want:= a symbol > > > > that indicates the code currently being compiled is newlib itself s= o that the > > > > header can change behavior for that environment specifically. is t= hat what > > > > it's meant for ? > > > >=20 > > > > if so, why does it seem to be inconsistently defined ? newlib/conf= igure.host > > > > will add it for a few random targets, as does the mips-specific > > > > newlib/libc/machine/mips/Makefile.am, as do a few specific winsup/c= ygwin/ > > > > files. it feels like the patch below is what we should have. > > > >=20 > > > > if that's not what this is for, is there a define that has this mea= ning ? > > > > in the glibc & gnulib world, the plain _LIBC define indicates this. > > >=20 > > > _COMPILING_NEWLIB might be older than that. In Cygwin we certainly n= eed > > > it during build. Your patch looks good to me, did you test it for so= me > > > targets? > >=20 > > yes, i tested it for bfin-elf and with a change that needed it in ctype= =2Eh. > > the ctype.h change didn't work until i updated the build this way. >=20 > uhm... why does a change in a header file depend on the build system? > That sounds weird. i'm making a fix to ctype.h that would utilize _COMPILING_NEWLIB as part of its fix. i was holding off posting that until the question of this symbol could be sorted out. > I tested building on Cygwin, which looks good. >=20 > So, here's a question: The patch is ok, just a change to the commit > message would be nice. However, would you like to take the opportunity > to change _COMPILING_NEWLIB to _LIBC throughout? That's something we > should have done long ago, I guess. let me do it as a series. _LIBC is already used in newlib, so i'm afraid it might not be as clean as just renaming the define. but i'll give it a shot and see what blows up. -mike --q2kYuhCYFibSzVRe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmGJaPgACgkQQWM7n+g3 9YHT1BAAhxVfKY0TYHd6uTvZxF0vnk75enHCF5kb3Jz4Jku4gpzEmkxiaI7mNPsD 13oyB+HhWIpn1rrLVrfVZMd9iUrlLa8b0vWL0gj3WKsSZ5Ymzj+Fujx4T0QwqwUM e2039oK2O9t+/4grgkO0aaHpaASIthRHW+oAjGRfG8Or+i2Bj+Fbg4os6Xlt+qOV zNcxRpNceN554yKMRQdYAQNFvoR+JXAPob0gfe1zHwWQRzeTshumvG60tIky7BrF DGBn7otUA7KyeEeguvbYH499OMsvrzVrb7qTe5pFPQvWpdjqB2DazEu7FrbtcNuH 4aZKX5K7vgElno1r2FxIIR8aCrRbJAS3vyDaGtj1IGzvo7BX5VzXSY08j9UO02wr TjLo0bG1AKEOxMG4k+rxHEF5cfg5k3oYlUAgWD2BnKXcOTzT10lSY0soCzIIGIkt utNW+98x9VfKYkUQpkrYMu4cC7JLW0KbrdxTZ7gFBZlNU9cGIY1EneXw2zGAqk/q MSfK+MFWKoOFhafyzlUkYLuVw3PCGEnY9lI8/TSoA+CK90issQsZ4l8z8cZBxgex E8Ylv6kswO1dFgqR+FVoibcFvQHOSTitBYwQKaU7C82rQxNLIZNrM886AJjmJn6V 8ycDZWNTKoQSyyYWxGSgca7mkAfttHnTeBaiQyaB7bmD8YRb3VE= =ZuUi -----END PGP SIGNATURE----- --q2kYuhCYFibSzVRe--