From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from re-prd-fep-043.btinternet.com (mailomta31-re.btinternet.com [213.120.69.124]) by sourceware.org (Postfix) with ESMTPS id 84BC7385E037 for ; Mon, 21 Feb 2022 18:05:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 84BC7385E037 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from re-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.54.5]) by re-prd-fep-043.btinternet.com with ESMTP id <20220221180542.BPCT390.re-prd-fep-043.btinternet.com@re-prd-rgout-002.btmx-prd.synchronoss.net>; Mon, 21 Feb 2022 18:05:42 +0000 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613A8DE8159331CF X-Originating-IP: [86.139.167.74] X-OWM-Source-IP: 86.139.167.74 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvvddrkeeigddutdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepheduueevueejueejgeeufeehtddtkeevtdduieelfeetteeffeejjedukeefgffgnecuffhomhgrihhnpegthihgfihinhdrtghomhenucfkphepkeeirddufeelrdduieejrdejgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddruddtfegnpdhinhgvthepkeeirddufeelrdduieejrdejgedpmhgrihhlfhhrohhmpehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkpdhnsggprhgtphhtthhopedvpdhrtghpthhtohepnhgvfihlihgssehsohhurhgtvgifrghrvgdrohhrghdprhgtphhtthhopehvrghpihgvrhesghgvnhhtohhordhorhhg X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.103] (86.139.167.74) by re-prd-rgout-002.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 613A8DE8159331CF; Mon, 21 Feb 2022 18:05:42 +0000 Message-ID: <5dc5d2ce-668b-49ac-bbf4-bbf0cdcb3da7@dronecode.org.uk> Date: Mon, 21 Feb 2022 18:04:58 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [PATCH v2] newlib: libm: merge build up a directory Content-Language: en-GB To: Mike Frysinger , "newlib@sourceware.org" References: <20220212203450.19650-1-vapier@gentoo.org> <20220217044256.5483-1-vapier@gentoo.org> From: Jon Turney In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3570.8 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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:05:46 -0000 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 = ... $(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 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. >>> >>> 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. >>> >>> 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 objects >> >> 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 `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 >> >> 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. >> >> Can you please take a look? > > how do you build cygwin ? i've just been doing w/newlib-cygwin git checkout: > $ ./configure --target=i686-pc-cygwin && make > $ ./configure --target=x86_64-pc-cygwin && make > these are passing for me You'll need to apply this patch: https://cygwin.com/pipermail/cygwin-patches/2022q1/011766.html Otherwise, you are linking with a stale libm.a left in your builddir from before these changes.