From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 6E0103858C2C for ; Mon, 21 Feb 2022 18:28:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6E0103858C2C 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 D553B34366B; Mon, 21 Feb 2022 18:28:30 +0000 (UTC) Date: Mon, 21 Feb 2022 13:28:31 -0500 From: Mike Frysinger To: newlib@sourceware.org Subject: Re: [PATCH v2] newlib: libm: merge build up a directory Message-ID: Mail-Followup-To: newlib@sourceware.org References: <20220212203450.19650-1-vapier@gentoo.org> <20220217044256.5483-1-vapier@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="K3nvTbsWIlKlKC+N" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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, 21 Feb 2022 18:28:33 -0000 --K3nvTbsWIlKlKC+N Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 21 Feb 2022 13:00, Mike Frysinger wrote: > On 21 Feb 2022 12:20, Corinna Vinschen wrote: > > On Feb 16 23:42, Mike Frysinger wrote: > > > Convert all the libm/ subdir makes into the top-level Makefile. This > > > allows us to build all of libm from the top Makefile without using any > > > recursive make calls. This is faster and avoids the funky lib.a logic > > > where we unpack subdir archives to repack into a single libm.a. The > > > machine override logic is maintained though by way of Makefile include > > > ordering, and source file accumulation in libm_a_SOURCES. > > >=20 > > > One thing to note is that this will require GNU Make because of: > > > libm_a_CFLAGS =3D ... $(libm_a_CFLAGS_$(subst /,_,$(@D))) > > > This was the only way I could find to supporting per-dir compiler > > > settings, and I couldn't find a POSIX compatible way of transforming > > > the variable content. I don't think this is a big deal as other > > > Makefiles in the tree are using GNU Make-specific syntax, but I call > > > this out as it's the only one so far in the new automake code that > > > I've been writing. > > >=20 > > > Automake doesn't provide precise control over the output object names > > > (by design). This is fine by default as we get consistent names in a= ll > > > the subdirs: libm_a-.o. But this relies on using the same set > > > of compiler flags for all objects. We currently compile libm/common/ > > > with different optimizations than the rest. > > >=20 > > > If we want to compile objects differently, we can create an intermedi= ate > > > archive with the subset of objects with unique flags, and then add th= ose > > > objects to the main archive. But Automake will use a different prefix > > > for the objects, and thus we can't rely on ordering to override. > > >=20 > > > But if we leverage $@, we can turn Automake's CFLAGS into a multiplex > > > on a per-dir (and even per-file if we wanted) basis. Unfortunately, > > > since $@ contains /, Automake complains it's an invalid name. While > > > GNU Make supports this, it's a POSIX extension, so Automake flags it. > > > Using $(subst) avoids the Automake warning to get a POSIX compliant > > > name, albeit with a GNU Make extension. > > > --- > > > v2 > > > - rebased onto latest tree > > > - fixed a parallel build issue with generated newlib headers & libm o= bjects > >=20 > > This patch breaks Cygwin. Unfortunately I didn't try to build myself, > > but only inspected the patch, so I didn't realize the problem. > >=20 > > First of all, Cygwin takes libm.a from newlib/libm/, not from newlib. > > This is easily fixable. > >=20 > > However, even after fixing this, we get a link stage error for *all* > > fenv functions: > >=20 > > ld: x86_64-pc-cygwin/newlib/libm.a(libm_a-fenv.o): in function `fegeten= v': > > newlib/libm/machine/x86_64/../shared_x86/fenv.c:160: > > multiple definition of `fegetenv'; > > x86_64-pc-cygwin/newlib/libm.a(libm_a-fegetenv.o): > > newlib/libm/fenv/fegetenv.c:65: > > first defined here > >=20 > > For some reason, libm.a contains both definitions of the fenv functions, > > the x86_64 definitions from newlib/libm/machine/shared_x86, as well as > > the fallback definitions from newlib/libm/fenv. > >=20 > > Can you please take a look? >=20 > how do you build cygwin ? i've just been doing w/newlib-cygwin git check= out: > $ ./configure --target=3Di686-pc-cygwin && make > $ ./configure --target=3Dx86_64-pc-cygwin && make > these are passing for me i still want to know how to repro your failure so i can make sure my local testing is sufficient, but i might have figured it out. we seem to have hit a bug in `ar` :(. this should workaround it. i'll take it upstream to binutils once we settle things here. -mike --- a/newlib/Makefile.am +++ b/newlib/Makefile.am @@ -124,6 +124,13 @@ libm_a_CCASFLAGS =3D $(AM_CCASFLAGS) $(libm_a_CCASFLAG= S_$(subst /,_,$(@D))) $(libm libm_a_CPPFLAGS =3D $(AM_CPPFLAGS) -I$(srcdir)/libm/common $(libm_a_CPPFLA= GS_$(subst /,_,$(@D))) $(libm_a_CPPFLAGS_$(subst /,_,$(@D)_$(/dev/null 2>/dev/null || cp libc.a libg.a $(libm_a_OBJECTS): stmp-targ-include =20 +libm.a: $(libm_a_OBJECTS) $(libm_a_DEPENDENCIES) + $(AM_V_at)rm -rf $@ $@.tmp && mkdir $@.tmp + $(AM_V_AR)for o in $(libm_a_OBJECTS); do cp $$o $@.tmp/ || exit $$?; done= ; \ + $(AR) $(ARFLAGS) $@ $@.tmp/*.o + $(AM_V_at)rm -rf $@.tmp + $(AM_V_at)$(RANLIB) $@ + @HAVE_MULTISUBDIR_TRUE@$(BUILD_MULTISUBDIR): @HAVE_MULTISUBDIR_TRUE@ $(MKDIR_P) $@ =20 --K3nvTbsWIlKlKC+N Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmIT2c4ACgkQQWM7n+g3 9YG3kA/9H/NDJwIQhRRtFNzL5urBQGNrVfk7BO+6RmQDx0/jWdQnId/JcHs/xMKK EJH2kjnMKg/nKg0MoaCSSj9RA1qpaszViS6c4rPisUltbXOzETYFfbaDcRMqcPWF xELyCsp753cj5xVWffONF99MSsKT/rknckfUboUL74xw8ehlOsB6TD8KgwogDH7f QAjtT/NpdIFLLZzLdoZg6GOTBCiuAWC3NJJk2vpa7e4fr/6MJV3gYn58LKrqqLXH ivLEmsclZteJ8N8+8BSNrwnLauNqdi1Y7ANMmwkKCOZ/ZEywuQjTlizKW+aR/6Mz aIZsSFZmoSnUmN0cbt1/T7VQydeppH63pTVtzLvCLHcZEtcAIsgFVEKhwXVSJZYo YFMMabq/NNw2kvvvPWQungpJxidAHDyX/E9QvLAG16RPvhy9Lg4SXAgkEUI+ZibF 6wsotB8Z3BNlRxEDejvuyKssSWb7zqJVR/q6v/QFR9zUH6NSHJMq5YAvgFc1tS9y nAgxoPto6cHAdzKSdpySObT97i5uamNhelxhyXmDvkNbKOGLPKz0XjlFPZPVRySC iyPXWJfX0BoDQguhxoKnVcFws5EeSAEYXEEMZnmnvRMnZeBBfM8B4AaKtXPkPzWN bGL9y98PErG5KZjF2HBrB6eEamLqbFaA6Gt/HuzHBEjhNIKJE7k= =KyX/ -----END PGP SIGNATURE----- --K3nvTbsWIlKlKC+N--