From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 03 Feb 2025 09:37:31 +0100 Received: from metis.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::104]) by lore.white.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1terxS-007uP1-1j for lore@lore.pengutronix.de; Mon, 03 Feb 2025 09:37:31 +0100 Received: from localhost ([127.0.0.1] helo=metis.whiteo.stw.pengutronix.de) by metis.whiteo.stw.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1terxS-0003xW-WB; Mon, 03 Feb 2025 09:37:31 +0100 Received: from imap5.colo.codethink.co.uk ([78.40.148.171]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1terxM-0003xM-4N for ptxdist@pengutronix.de; Mon, 03 Feb 2025 09:37:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codethink.co.uk; s=imap5-20230908; h=Sender:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From :Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KrDUXh6gNMqPnbj0wqJ4Mf8XpdEuHYbu2RUGriYk4p8=; b=ksbGdzg8cH5D0GGxvKDMRlwvDe eFRjPwdHnMaqeYKuV2e7VMG1QhS0IPzHVwxteJ8JFvJt75mWYcQpL8Ig0xz7fyMGZ5NEee1GGDkeY kDKLQAZW7hLCkyDM8kRfrj4BxE/zrF51D7dSQQ0R7dsGz6sJP4M41L7h9+xGxHU2fRHGb/oh+KM5o ZGkHNtZWp5lrqU5xdfs8BjMyrrhtSBX5QRFrspDcP9aDZHIhsEIwgBld/fi2Is4KqBCzTM1MSOYPE vngYQJ9RpRGDxvvoKcSH4bWtPRiDMDdYLg66MjDbct5hyhFkHaqD7L5wkBSuZx8UaMMfYAq+UtMpq cLKV7ToQ==; Received: from 241.112.159.143.dyn.plus.net ([143.159.112.241] helo=[192.168.1.147]) by imap5.colo.codethink.co.uk with esmtpsa (Exim 4.94.2 #2 (Debian)) id 1terxK-000mvm-Tl for ; Mon, 03 Feb 2025 08:37:22 +0000 Message-ID: Date: Mon, 3 Feb 2025 08:37:22 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: ptxdist@pengutronix.de References: Content-Language: en-US From: John Graham In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on metis.whiteo.stw.pengutronix.de X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Subject: Re: [ptxdist] Building x86_64 without host libs (e.g. zlib) 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.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false Thanks - it's purely so that we have a toolchain that doesn't rely on host tools, so that it can be distributed to other systems without requirements on host tools. Sounds like this approach is going to take a lot of work though so I think we'll look for another way. Thanks for the help! John On 02/02/2025 11:42, Michael Olbrich wrote: > On Fri, Jan 31, 2025 at 03:41:05PM +0000, John Graham wrote: >> I'm trying to build an x86_64 toolchain that's independent of the host. By >> default in the ptxconfigs/x86_64-unknown-linux-gnu_gcc config, it has e.g. >> `PTXCONF_HOST_SYSTEM_ZLIB=y`. I expected I could set this to `=n`, but when >> I do that, `ptxdist go` fails with: >> >> ``` >> >> ptxdist: error: 'host-system-zlib' is not selected. >> ptxdist: error: This can happen if the ptxconfig is outdated or >> ptxdist: error: the package is disabled for the current architecture >> >> ``` >> >> Can anyone tell me if this is the proper approach to disabling use of the >> host libraries, and/or what I'm doing wrong? Any help appreciated! > There are issues on multiple levels: > > 1. just changing the config file will not make the dependency go away. If > you look at the package rules in rules/ you'll see multiple ones that have > 'select HOST_SYSTEM_ZLIB'. That's what is causing the error you're seeing. > > 2. Even if you remove those, building will probably fail. The dependency is > there for a reason. You would definitely need to remove the > --with-system-zlib that's there in several places. But I'm not sure, if > that's enough. It's quite possible that for some of the packages, zlib is > a hard requirement. > > Why would you want to build without zlib anyways? It's not the only > requirement and removing just that seem odd. > > Michael > -- John Graham (he/him) Software Engineer Codethink Ltd 3rd Floor Dale House 35 Dale Street Manchester M1 2HF United Kingdom Codethink delivers cutting edge open source design, development and integration services. http://codethink.co.uk Office: 0161 236 5575