From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: i686-linux GCC package on x86_64 Date: Fri, 04 Oct 2019 21:54:09 -0700 Message-ID: <87pnjbdc7i.fsf@gmail.com> References: <87d0fs2q0p.fsf@ambrevar.xyz> <87d0featrl.fsf@ambrevar.xyz> <87h84p3trz.fsf@gmail.com> <877e5lnd81.fsf@ambrevar.xyz> <87r23s1qy1.fsf@gmail.com> <87v9t4a4yk.fsf@jlicht.xyz> <20191004181644.589c8ea3@scratchpost.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:43876) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iGc5E-000706-7W for guix-devel@gnu.org; Sat, 05 Oct 2019 00:54:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iGc5D-000872-0u for guix-devel@gnu.org; Sat, 05 Oct 2019 00:54:20 -0400 Received: from mail-pl1-x62b.google.com ([2607:f8b0:4864:20::62b]:32923) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iGc5C-00086M-RU for guix-devel@gnu.org; Sat, 05 Oct 2019 00:54:18 -0400 Received: by mail-pl1-x62b.google.com with SMTP id d22so4108651pls.0 for ; Fri, 04 Oct 2019 21:54:18 -0700 (PDT) In-Reply-To: <20191004181644.589c8ea3@scratchpost.org> (Danny Milosavljevic's message of "Fri, 4 Oct 2019 18:16:44 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Danny Milosavljevic Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Danny Milosavljevic writes: > On Fri, 04 Oct 2019 17:46:43 +0200 > Jelle Licht wrote: > >> Mathieu Othacehe writes: >>=20 >> > >> > --8<---------------cut here---------------start------------->8--- >> > (native-inputs >> > `(,@(if (not (string-prefix? "i686" (%current-system))) >> > `(("cross-gcc" ,(cross-gcc "i686-unknown-linux-gnu")) >> > ("cross-binutils" ,(cross-binutils "i686-unknown-linux-gn= u"))) >> > '()))) >> > --8<---------------cut here---------------end--------------->8--- >> > >> > that uses the current gcc if you're already building on an i686 system, >> > or define and use a cross-gcc targeting i686 systems otherwise.=20=20 >>=20 >> This snippet might make a lot of sense to seasoned schemers/guixfolk, > > Basically just ignore the birdshit characters to understand what it does = :) > > The first unquote is to evaluate (%current-system) at the toplevel which = is > what interprets the package definitions in the first place. > > "`(,@" is a no-op. Not sure why it's written like that. > >> `(("cross-gcc" ,(cross-gcc "i686-unknown-linux-gnu")) >> ("cross-binutils" ,(cross-binutils "i686-unknown-linux-gnu"= ))) > > is like we always write inputs, but it's calling the "cross-gcc" function= in the > toplevel in order to get the package to use. Perhaps it's because of the "if" expression. >> with the multiple levels of (un)quoting and what not. It does not seem >> like what somebody with little experience in either would think of by >> themselves. >>=20 >> Would it make sense to have a section/stub in the cookbook about cross >> compilation? > > I don't think that cross-gcc is stable API that much--and it's not > common that you need it anyway. A normal user just cross compiles > by using > > guix build --target=3Di686-linux pkg > > or better yet, uses qemu to natively compile it for a foreign system > > guix build --system=3Di686-linux pkg > > . > > The above is only necessary when for some reason your package has > parts which only compile on one system and other parts which only > compile on another system--that's very rare. > > Nowadays, packages are supposed to be cross-platform, so using cross-gcc > directly is unnecessary, too. > > Right now cross-gcc is not documented, so I guess that counts as > "not a public interface". Yeah. I'm inclined to agree with Danny. With Guix, it is best to cross-compile in the way Danny is suggesting. If there are projects that require other tricks to cross-compile, perhaps they would be interesting to discuss. I feel like there may be a lot of "quick and dirty" projects with non-standard build logic that can't easily be packaged into Guix for cross-compilation. That said, I am curious about something. If I want to make a cross-compiler available for the purpose of hacking around on some code and cross-compiling it, is there an equivalent to "guix package -i gcc-toolchain" which will give me a cross-compilation toolchain? My feeling was that Guix can create cross-compilation toolchains on demand, but there is no UI exposed for making it available via a guix command, since people are encouraged to just ask for the cross-built product. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAl2YIfEACgkQ3UCaFdgi Rp3qoxAAkcK12Z1cyijvCnJEyUOKxv5yRicLEEtSjBmfkJRY17hp6L9QW9u7bz7m +lhzr4+bXMHusWkiba44l5RcNGUnuAfD9ifavSOgWXatyStl82v9lXVlgZbHZtD3 huVJQTWKQpHQxVpIgyw7qb9Yv4mKhvXSocaDYzP0bL7lMZ0iFQ5msE2otVeIGlcp 30FHrG6+0ZtKbcGWMhPV8bqfTi8MQOZRMDbtnIGSP9VT7Ur73g5W4zbJGtDSuKSL jhuPZQ+bbxVzDYTQ/Oelv3yuQYpgjB8pqRykJ60VnhMnHRcoosFfUOGsG1z4w2HK RiUFj9aoEWsvRxRyGC+LsiVq3ixLj+Jh2yxyVTv7MRiwrENCAGieV5pH+fa/6olq mQkigU+ziDV9pYiGqw2mQJxSAJbwCURzKWGzVHNyCcHJGDHI93PB5hPDhmaebLwj pCHhtKJwjixKxV6BtG36KD0wmc4PO1QsIp1wgbK5KxhUEFnTrDJm/xqnqsjLf1uk 0hsfkQ2ZJkQIwNQdUCHODqx+3s7bNPzvRxMNaDYG2meGtM5PwiLmi4hp+bru7kPK otkq43uVsGXww+zIWM7VS5cqdgtH3S9EM0hFcdKa6YCG2g8GvjYy/ZpiO+E3bbpx K2IISFDQDNdmmZlCDGiAzHDIpp7ytb4ZYq9rv4sE8SD6VDYp+HY= =P7Ft -----END PGP SIGNATURE----- --=-=-=--