From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: bug#37801: Possible insight into issue #30756 #include_next bug Date: Sat, 19 Oct 2019 14:53:36 +0200 Message-ID: <20191019145336.4fb5af37@scratchpost.org> References: <20191018020344.78cbee48@scratchpost.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/Fn02UGuZ8HR5l0NBynLtmuc"; protocol="application/pgp-signature"; micalg=pgp-sha256 Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:35478) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLoF9-0007Kb-6d for bug-guix@gnu.org; Sat, 19 Oct 2019 08:54:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iLoF8-0005mg-0M for bug-guix@gnu.org; Sat, 19 Oct 2019 08:54:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:43269) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iLoF7-0005mW-Tr for bug-guix@gnu.org; Sat, 19 Oct 2019 08:54:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iLoF7-0004si-Rz for bug-guix@gnu.org; Sat, 19 Oct 2019 08:54:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Carl Dong Cc: "37801@debbugs.gnu.org" <37801@debbugs.gnu.org> --Sig_/Fn02UGuZ8HR5l0NBynLtmuc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, On Fri, 18 Oct 2019 14:02:33 +0000 Carl Dong wrote: > Perhaps Ludovic can confirm this, but I believe the reason why Guix is not > setting up CROSS_CPATH is because it doesn't _know_ it's cross-compiling.= =20 Ah, that makes a lot of sense! But the "cross-gcc" returns a cross compiler that should know that we're cross-compiling (but it sets up SEARCH-PATHS with CROSS_LIBRARY_PATH and CROSS_CPATH, but not NATIVE-SEARCH-PATHS. Hmm). But the fundamental problem remains that guix host-side can't know whether we are cross compiling from this. It has its own cross-compiling support at the toplevel, at the guix command line. The following is only tangentially related to your issue, so maybe not so useful to you: I've also tried (define (xcross base-package) (package (inherit base-package) (search-paths '()) (native-search-paths (list (search-path-specification (variable "CROSS_LIBRARY_PATH") (files '("lib" "lib64"))) (search-path-specification (variable "CROSS_CPATH") (files '("lib" "lib64"))))))) and=20 (native-inputs `(("pkg-config" ,pkg-config) ("cross-gcc" , (xcross (cross-gcc "arm-linux-gnueabihf" #:xbinutils (cross-binutils "arm-linux-gnue= abihf") #:libc (xcross (cross-libc "arm-linux-gnuea= bihf"))))))) ;("cross-libc" ,(xcross (cross-libc "arm-linux-gnueabihf"))) ; header= files ("cross-libc-static" ,(xcross (cross-libc "arm-linux-gnueabihf")) "s= tatic") ("libusb" ,libusb))) for sunxi-tools. But that didn't work correctly either. What I'm trying to do is a little different from what you are trying to do. sunxi-tools has some parts that are supposed to be run on the embedded syst= em in question and some that are supposed to run on the host (both are GNU system= s). For convenience, I'm (and upstream are) trying to provide both in the derivation--I think because the tools can send a program via USB to the emb= edded system. So if you compile sunxi-tools on x86_64, you get host tools for x86_64 and = target tools for ARM. If you compile sunxi-tools on x86_64 for RISC-V, you get host tools for RISC-V and target tools for ARM. So it basically has to override the "which cross compiler" setting later in the compilation process. The more I think about it the more I'm getting the feeling that I should st= op trying to fit a square peg into a round hole and just add an extra package for the target tools. So I did the latter. See guix-patches patch# 37823 which is now very nice. Thanks for bringing the cross compilation topic up :) --Sig_/Fn02UGuZ8HR5l0NBynLtmuc Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl2rB1AACgkQ5xo1VCww uqWpEQf7BYjRWTf6FxSmHJtWLtxqIQXHNcVuBMoygghLRcK+iQ+60l6deyHskjSo N0PRD36rIRswGr5QKcjXij6j/VS0K9yTUltfAVx03UiH7/SYpEfpfKnLTQGKeVVE JaqK7KaOiWP0xAuVrQCsO00QYlQctzBpex5T4Jc8ugCUM837byQAjjup6RZ708Ni dWTGIGGZrgOiy8T6yvzHWse/4EUJS8jQmAdk18zWzoyIP6VXOP0IAELcgLe443OG eaKw/hGmrj8W0mEjWOPEUHJMgNzo5tI3ESea7xUQgcITk6cKFdxDmD9S9SKrMQux CmqmCGpa2iU3edhJ3bPcfWQM12wlQg== =up/c -----END PGP SIGNATURE----- --Sig_/Fn02UGuZ8HR5l0NBynLtmuc--