From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 17 Nov 2022 15:52:52 +0100 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by lore.white.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ovgG4-00AJJ3-Gr for lore@lore.pengutronix.de; Thu, 17 Nov 2022 15:52:52 +0100 Received: from localhost ([127.0.0.1] helo=metis.ext.pengutronix.de) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1ovgG3-0008Nc-0a; Thu, 17 Nov 2022 15:52:51 +0100 Received: from mail.benfm.de ([85.214.52.64] helo=mx1.benfm.de) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ovgFY-0008NT-8J for ptxdist@pengutronix.de; Thu, 17 Nov 2022 15:52:20 +0100 Message-ID: <2c61d58d-3b73-45aa-eb67-e55ce576909c@benfm.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=benfm.de; s=2020; t=1668696738; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=25ilttamGyNEXL7HKAz+rSBGemCa0xoTCqHmergcXtM=; b=WxuXb0bW1q5YmaSKIF6VJ2PLJ3DLvuYkJ+OYhOQFs07k0jX4F0iHc9Q0OGWukmVriAxmEf Bm2isra7JRal4T2tw7wycCTTFZTkABfZ6UAG/nUSviq2e6Q9emq49Dqf5gKWmW8j8KtREK bbV5UCtRIOYstFg9s0mY3/9jDXvttdgVYdXi1tK3g6CIfv5ZobzN6Lak3xmK5GfFfBfXjd LtNnGnxkwKVyYzVr2gROy1cB/N92GCwLhVyEeTsVOQZp6kez2QOAjzmuQyND9J98lMWK7K UTVFaL9wae9V+eIlfsNMpIUAUxxhNs60HswDA7ncyrUhkQX7qWYCyg2n1rcqFg== Date: Thu, 17 Nov 2022 15:52:18 +0100 MIME-Version: 1.0 From: Felix Mellmann To: ptxdist@pengutronix.de References: <35a025e1-9b3b-01f5-6776-db2ce5554208@benfm.de> <20221116071710.GH30335@pengutronix.de> <55c7407e-88b8-85cb-5b3d-5556e7cdeb91@benfm.de> <20221117074550.GJ30335@pengutronix.de> Content-Language: en-US In-Reply-To: <20221117074550.GJ30335@pengutronix.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on metis.ext.pengutronix.de X-Spam-Level: X-Spam-Status: No, score=-1.9 required=4.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Subject: Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0 X-BeenThere: ptxdist@pengutronix.de X-Mailman-Version: 2.1.29 Precedence: list List-Id: PTXdist Development Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: ptxdist@pengutronix.de Sender: "ptxdist" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: ptxdist-bounces@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false On 17.11.22 08:45, Michael Olbrich wrote: > On Wed, Nov 16, 2022 at 06:40:02PM +0100, Christian Melki wrote: >> On 11/16/22 15:08, Felix Mellmann wrote: >>> On 16.11.22 08:17, Michael Olbrich wrote: >>>> On Sun, Nov 13, 2022 at 06:32:01PM +0100, Felix Mellmann wrote: >>>>> I've just run into a linker problem when building e2fsprogs 1.46.5 using >>>>> OSELAS.Toolchain 2022.10.0 (arm-v7a-linux-gnueabihf): >>>>> >>>>> >>>>> ------------------------- >>>>> target: e2fsprogs.compile >>>>> ------------------------- >>>>> >>>>> make: Entering directory >>>>> '/PTXdist/BSP/platform-imx6/build-target/e2fsprogs-1.46.5' >>>>> cd ./util ; make subst >>>>> make[1]: Entering directory >>>>> '/PTXdist/BSP/platform-imx6/build-target/e2fsprogs-1.46.5/util' >>>>>     CREATE dirpaths.h >>>>>     CC subst.c >>>>>     LD subst >>>>> lto1: fatal error: bytecode stream in file 'subst.o' generated with LTO >>>>> version 11.2 instead of the expected 11.3 >>>>> compilation terminated. >>>>> lto-wrapper: fatal error: /usr/bin/gcc returned 1 exit status >>>>> compilation terminated. >>>>> /usr/bin/ld: error: lto-wrapper failed >>>>> collect2: error: ld returned 1 exit status >>>>> make[1]: *** [Makefile:369: subst] Error 1 >>>>> make[1]: Leaving directory >>>>> '/PTXdist/BSP/platform-imx6/build-target/e2fsprogs-1.46.5/util' >>>>> make: *** [Makefile:194: util/subst] Error 2 >>>>> make: Leaving directory >>>>> '/PTXdist/BSP/platform-imx6/build-target/e2fsprogs-1.46.5' >>>>> make: *** >>>>> [/usr/local/lib/ptxdist-2022.11.0/rules/post/ptxd_make_world_compile.make:20: >>>>> /PTXdist/BSP/platform-imx6/state/e2fsprogs.compile] Error 2 >>>>> >>>>> The error vanishes if ./configure is called with "--disable-lto" instead of >>>>> "--enable-lto". >>>>> >>>>> As I'm no expert at this level, I hope anyone could put some hints about the >>>>> issue. >>>> Is this a clean build? I've not seen this here with the same toolchain and >>>> the error looks like you're mixing compiler versions. >>> It was a clean build, yes. But finally - ccache messed it up. After >>> clearing the cache the build was successful. >>> >>> Well I should loose my trust in ccache ... Please drop my patch. >>> >> I still think that LTO should not be enabled per project like that. > It's a good point. So I may apply the patch with a modified commit message. > I'm not sure yet. > >> Regardless if it's working or not. >> A global for LTO would be much better. > Sneaking it in via compiler wrappers does not work. It breaks quite a few > packages (I tried that some time ago). But maybe a global option that > selected packages can use to enable it conditionally. Grepping through the packages reveals, that 8 packages explicitly disable LTO and only e2fsprogs enables LTO. For the rest I'm unsure about the defaults. So what should a global LTO option look like and what should be the consequences? (i.e. replace all the enable/disable-lto with the global option? Enforce a setting for all packages not configuring a default?) @Michael: you propose that I should resend the patch with a different commit message? Do you have a proposal? I really don't have a clue why LTO is enabled for this peculiar package and its consequences and I unfortunately run into a random ccache issue .. > > Michael >