From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 39DD0385E00E for ; Mon, 21 Feb 2022 18:00:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 39DD0385E00E 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 7808D3431CE; Mon, 21 Feb 2022 18:00:27 +0000 (UTC) Date: Mon, 21 Feb 2022 13:00:27 -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="HC68YRFG8yJOhkIY" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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:00:30 -0000 --HC68YRFG8yJOhkIY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 all > > 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 intermediate > > archive with the subset of objects with unique flags, and then add those > > 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 obj= ects >=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 `fegetenv': > 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? how do you build cygwin ? i've just been doing w/newlib-cygwin git checkou= t: $ ./configure --target=3Di686-pc-cygwin && make $ ./configure --target=3Dx86_64-pc-cygwin && make these are passing for me -mike --HC68YRFG8yJOhkIY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmIT0zsACgkQQWM7n+g3 9YHQtg//XErN1bSS3PDhJ2ZOe/P/XFC82zh61uJ3wIPdS6mT1G/ExCa983avksR6 kZQUqHvIYT9VCSdDffam8YgCnpnNPUmK4a6EzfhwzT4UTO9sebEGSQcS+He+1WoJ MMqonmf7ONUHBM8pZGwTrDysd05zbt34GO8YtFuIdfqdZKJamdve8qv26EXXx9mX B3+d1Odc5fJPosf2VBu8yNk1iYDh7IpL2Y8+8d4h9jKnNYCDE9+GqFTwXUMauQEA FVe+401QHDaFisMWBs5pSer5T/o4oG2QvGTPq9o4807xpfTVNx1J3EZeFRPn3CH/ mcxCk3B1kP7AcdmuT9WACnvPM26FTH07850QI/z4msDdJIVW4GFBKyOV9XqjPuC7 +yo0v4pwVvx2djwUr6/l0vYzSdUZrXExCA60JKFAh0rqcHAJlzPUncamWjK2HnoM beeIQveokMuM0tH3xKpdxl44kSzDtcTSEvYhR5gdjtZsxK6oAPl57I96fsqiCm5G 6W83s7o4QTo/KG9tyMxg9mkjwvEFzo3Am41Btxu/+G584w4IDr2Z3aZgMU9Wxge1 x0CLhcyZiH9VpoEnHy6gZydYCGn9nP1U/ZkfmwT0UoXCoxNyiHkS8C9i6FpClPCi xolIw8YJ65wuyp9GWVgyrZ3LbFr9uRmF3G0q4iVOfzvVlw4JQRQ= =ffiV -----END PGP SIGNATURE----- --HC68YRFG8yJOhkIY--