From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id 835793858C42; Tue, 23 Apr 2024 08:52:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 835793858C42 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cebitec.uni-bielefeld.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 835793858C42 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.70.160.84 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713862369; cv=none; b=JtENJSqVPkilYTIUXj4zf/jgzt08cTIKNHLn59jUhcrrsG6P9pb3XHYABkOa3E2wjhFPCCiAQwl1m7PkEV8LHSBhtdHoJFmsLpiGExpF0My83bmirn8xMJVCRCdfz3WYiddxnscgTmljZnu6+Xjsqa764QNqYoL+9LN2cVuwX94= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713862369; c=relaxed/simple; bh=xz+8tRSopKdWDsmmcbg29u4wU+/3T/S6L5NbL0zhGKs=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=OUf+kYVxpK70qn8hkQ2SjrQrbA/q4/RL0qMpH3OcNdxXktoBgnHMtC65Tk30HCllhzT3iaxXd87f3TwXXhlG1lUN4P+7E0oDXkqz1Z1wJ1xQh+IzOUkG+UwjXvhwywoMGx34nhLwI/bszHGLqSfV1UMzGzAR8liXWZ/Ao0ECNXk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 5EFA9B0259; Tue, 23 Apr 2024 10:52:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= cebitec.uni-bielefeld.de; h=content-transfer-encoding :content-type:content-type:mime-version:user-agent:message-id :in-reply-to:date:date:references:subject:subject:from:from :received:received; s=20200306; t=1713862364; bh=xz+8tRSopKdWDsm mcbg29u4wU+/3T/S6L5NbL0zhGKs=; b=FotILdDtjeOGsr2hvXjg4X2R6Y3o/8Q ZotP1SjwwrSRQUDgIBXgxM20MBuDFBDCe9wetUfx7+E/j2DynWXrk6tiblFq21Sk NPfYtCAJPBWpfSyV3lAej5wDzTBQ1DShFvHUcfc+BINgOzlbAO54hzfCfTBgtRi0 oDAC1qL2Kaocx3+kWMNogZbZmkf8fnXWNl8nroaiZbsEnA6fzQZ/qf3X6eEcu7hg Kv0zKYTsF/9SELs5FK4fdPQJb6lPlEtEzizNnjEg/fyFKntICwkyLYE0zoGbI5iw Nc4w/5AJKlBrLLg1fQgn+T3paOhE74rkVgONQvkgx4ob+ppHeHYE7nw== X-Virus-Scanned: amavisd-new at cebitec.uni-bielefeld.de Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2Y6WVBpDAkz7; Tue, 23 Apr 2024 10:52:44 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p50855b96.dip0.t-ipconnect.de [80.133.91.150]) (Authenticated sender: ro) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id 66F4EB09E9; Tue, 23 Apr 2024 10:52:44 +0200 (CEST) From: Rainer Orth To: Arthur Cohen Cc: Andrew Pinski , pierre-emmanuel.patry@embecosm.com, gcc-patches@gcc.gnu.org, gcc-rust@gcc.gnu.org Subject: Re: [PATCH] build: Check for cargo when building rust language References: <20240408163337.303317-2-pierre-emmanuel.patry@embecosm.com> <45ff25ab-b39e-4f2d-84bd-a3ee8cfff98a@embecosm.com> Date: Tue, 23 Apr 2024 10:52:43 +0200 In-Reply-To: <45ff25ab-b39e-4f2d-84bd-a3ee8cfff98a@embecosm.com> (Arthur Cohen's message of "Wed, 17 Apr 2024 16:54:19 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.90 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3783.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Arthur, > On 4/17/24 10:13, Rainer Orth wrote: >> Andrew Pinski writes: >>=20 >>> On Mon, Apr 8, 2024 at 9:39=E2=80=AFAM wrote: >>>> >>>> From: Pierre-Emmanuel Patry >>>> >>>> Hello, >>>> >>>> The rust frontend requires cargo to build some of it's components, >>>> it's presence was not checked during configuration. >>> >>> WHY did this go in right before the release of GCC 14? >>> I don't get why this is considered temporary and it goes in right >>> before a release. >>> That seems broken to me. >> two more questions about this: >> Right now, the new cargo configure test disable rust on all of my >> targets (Solaris, Linux, Darwin) which didn't have it installed. Before >> (as recent as last Friday), I could successfully build and test >> crab1/rust on all of them without cargo in sight. So I wonder if the >> patch isn't premature. > > We already have components depending on Rust libraries in our development > repository, so this patch is important to ensure errors are emitted early > during the configure phase rather than later at build time. I don't think > this is premature, considering that your targets would fail to build the > Rust frontend next time we upstream commits, which should happen this week > or early next week. it would have been very helpful to state this up front: introducing a dependency that's never used outside of a configure test right night is still damn confusing. An alternative might have been to commit this patch shortly before it's actually used. >> Besides, while there are packaged versions of cargo for Solaris 11.4 and >> Linux, Darwin hasn't anything (not checked Homebrew or similar yet). >> What's worse, rustup only supports macOS 10.12 and up, while I'm still >> regularly testing 10.7 and 10.11. I don't really feel like building >> rust from source here (if it works at all). This hasn't been an issue >> for any other languages that require additional tools for bootstrapping >> (like Ada or D): there are versions of GNAT around that still support >> those old Darwin releases, and I could use the C++ version of GDC in GCC >> 11. > > Sorry, I'm not too familiar with the Rust situation on macOS. I am reading > that starting from Rust version 1.74, the minimum macOS version required = is > indeed 10.12, released in 2016 I believe? > > We currently depend on Rust version 1.72, so you should be able to install > it on macOS 10.11. Maybe with rustup? You can try something like the > following: > > curl --proto '=3Dhttps' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y > --default-toolchain=3D1.72.0; I tried this with mixed success: while the part of the installation that goes into $RUSTUP_HOME at least can run cargo --version on both 10.7 and 10.11, the other one (for $CARGO_HOME) dies with SIGILL on 10.7 trying the same. However, when I ignore most of what's installed by rustup and point $PATH at .../toolchains/1.72.0-x86_64-apple-darwin/bin, I can run the cargo in there with --version even on 10.7. For the moment, that's good enough to get a trunk build/test with rust including working again, but of course this doesn't prove that this will remain so once cargo is actually used. > which is the default installation method for Rustup, with version 1.72 of > the language specified. I'm not able to test this, sorry, but I'm very > interested in knowing if it works. I think you can also install Rust using > Homebrew, but again I am not able to test this and apologize. I'll go down this route (or try installing rust from source) only if need be. > The goal is to reduce that Rust version further soon anyway - we are going > to target Rust version 1.49, released 3 years ago, as that is the version > that gccrs aims to compile. This will bring us closer to compiling our > dependencies with our own frontend. Good. At least knowing this it's easier to check what macOS versions are supported by e.g. 1.49. >> At the very least, the Rust situation needs to be documented clearly. > > I'd love to work on this - what sort of documentation do you have in mind? > Do you mean something like the online GCC documentation or an in-tree fil= e? > Let me know what you'd like me to add and I'll be happy to do so. I think this should go into gcc/doc/install.texi, as for all other languages and targets. This way you have all the necessary information in one place, while some in-tree file is almost guaranteed to be overlooked. Rainer --=20 ---------------------------------------------------------------------------= -- Rainer Orth, Center for Biotechnology, Bielefeld University