From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id F21EA3858C2C for ; Mon, 21 Feb 2022 18:30:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F21EA3858C2C 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 26C28342A5C; Mon, 21 Feb 2022 18:30:04 +0000 (UTC) Date: Mon, 21 Feb 2022 13:30:04 -0500 From: Mike Frysinger To: Jon Turney Cc: "newlib@sourceware.org" Subject: Re: [PATCH v2] newlib: libm: merge build up a directory Message-ID: Mail-Followup-To: Jon Turney , "newlib@sourceware.org" References: <20220212203450.19650-1-vapier@gentoo.org> <20220217044256.5483-1-vapier@gentoo.org> <5dc5d2ce-668b-49ac-bbf4-bbf0cdcb3da7@dronecode.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YbMvGIt4NrgX9snn" Content-Disposition: inline In-Reply-To: <5dc5d2ce-668b-49ac-bbf4-bbf0cdcb3da7@dronecode.org.uk> 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:30:09 -0000 --YbMvGIt4NrgX9snn Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 21 Feb 2022 18:04, Jon Turney wrote: > On 21/02/2022 18: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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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 > >> > >> This patch breaks Cygwin. Unfortunately I didn't try to build myself, > >> but only inspected the patch, so I didn't realize the problem. > >> > >> First of all, Cygwin takes libm.a from newlib/libm/, not from newlib. > >> This is easily fixable. > >> > >> However, even after fixing this, we get a link stage error for *all* > >> fenv functions: > >> > >> ld: x86_64-pc-cygwin/newlib/libm.a(libm_a-fenv.o): in function `fegete= nv': > >> 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 > >> > >> For some reason, libm.a contains both definitions of the fenv function= s, > >> the x86_64 definitions from newlib/libm/machine/shared_x86, as well as > >> the fallback definitions from newlib/libm/fenv. > >> > >> Can you please take a look? > >=20 > > how do you build cygwin ? i've just been doing w/newlib-cygwin git che= ckout: > > $ ./configure --target=3Di686-pc-cygwin && make > > $ ./configure --target=3Dx86_64-pc-cygwin && make > > these are passing for me >=20 > You'll need to apply this patch: >=20 > https://cygwin.com/pipermail/cygwin-patches/2022q1/011766.html >=20 > Otherwise, you are linking with a stale libm.a left in your builddir=20 > from before these changes. while i often test incremental changes, i `rm -rf` the build dir when runni= ng the full test suite to avoid possible issues like this. and in this case, both targets pass from a fresh build. -mike --YbMvGIt4NrgX9snn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmIT2iwACgkQQWM7n+g3 9YETsxAAiwZQnPyhAfDp/JhoVYIOMWOiiLyMhnQ+34BnC5UkNcfeVkP0+OpKzFGx fpR/0lPX8v/N4rBPH9b5btQwGmbqvvwIJMyw30BdNKn462/wqkdp9buLv94HAwR6 YdeY0lr9iIIdLgo275CrLYZIsJG/wlezQpg/C+0FR0WjBZdcfNCYs6aiIYuKjCYA fM5VJm9JvFQS6afp2XPsnL+ftX5JYQ83E49xu4gSu4ZuLMVUxi6Q+ND6TE7rWdXt dh9EaD32IhtT2XurQfQv1z0Sg9nCXNC5xt0ofo5jxaXMgalHRaxeSzrd0GbYVe8Q JAGj5x1C3ok2IhynmyrFdubAbCQaxjdJxHoa6XWJb/4PYDIokepIOtrzEs7mQJ8v XfVODFvbakoLIib4p8D1Hp6Q4uQzwUsWLFfKME8S8VETmxKCw7JZ4KBxrknq//5h ENar7XiIlb69SCFMp+Hq6++NEVRsh/YmdXXtmXKcGFswivvaMEyHjYvBggYg8x1e +FBuqZ3MskO3bHenyayCxM5Cw/RRPPrx9ZEvjNerKhBIgl9lKsOTk4iXJuUOGnHR 09HKOvTjhzzKxAg++7hYEOhrlo0l7EIwXADY2QCHiiHOqTcxlKBKbHWjtgBNF9Tp BUBxkZbSuK/dmCB8ncq/0PETPYuR9s+dhUVm6Z2J13WCoUQdN6A= =GSng -----END PGP SIGNATURE----- --YbMvGIt4NrgX9snn--