Possible insight into issue #30756 #include_next bug

OpenSubmitted by Carl Dong.
Details
2 participants
  • Carl Dong
  • Danny Milosavljevic
Owner
unassigned
Severity
normal
C
C
Carl Dong wrote on 17 Oct 2019 23:56
(name . bug-guix@gnu.org)(address . bug-guix@gnu.org)
xvTREYeVjwuadLzEDhqSwFNXRPLuxR08Q98lclES3tkQH13Drwv9EzhWNkXbR3XZN-Tc7KCLed7yhdThX8y09kfvqRorSSayyCrW8LkSoyc=@carldong.me
Hi all!
TLDR if you just want to know what's the final patch that worked, grep for"final patch which works is the following"
This is a long email, but it is only long because I want to be very clear and Iinclude a lot of snippets of code and logs.
I originally wrote my NSIS package (introduced in e214a22007) on top of7150743522, which was before the GREAT CORE-UPDATES MERGE. However, afterrebasing it over the GREAT CORE-UPDATES MERGE, the package stopped working. Myinvestigations into this failure has revealed some insights which might beuseful for other cross-compiling packages and for resolving the long-standing"important" issue #30756.
For some context, the NSIS package is somewhat special. It requires that bothnative compilers and mingw-w64 cross-compilers be available, as NSIS is aprogram used to create installers meant to be run on Windows.
My original method of achieving this in pre-GREAT CORE-UPDATES MERGE Guix can besee in e214a22007, whereby I added a 'fix-env phase. In that 'fix-env phase, Iwould remove mingw-w64 paths from CPLUS_INCLUDE_PATH, C_INCLUDE_PATH, andLIBRARY_PATH, and put them in CROSS_CPLUS_INCLUDE_PATH, CROSS_C_INCLUDE_PATH,and CROSS_LIBRARY_PATH respectively. This way, the native compilers won't thinkthat the mingw-w64 paths were something they were supposed to use and getconfused.
As part of the GREAT CORE-UPDATES MERGE, it would seem that CPLUS_INCLUDE_PATHand C_INCLUDE_PATH are no longer set in the build environment. Rather, onlyCPATH is set.
Now, you would think that the solution here is just to replaceCPLUS_INCLUDE_PATH and C_INCLUDE_PATH in my 'fix-env phase with CPATH like so:
Toggle diff (177 lines)diff --git a/gnu/packages/installers.scm b/gnu/packages/installers.scmindex c987254d61..9d29e32485 100644--- a/gnu/packages/installers.scm+++ b/gnu/packages/installers.scm@@ -92,7 +92,7 @@ ;; CROSS_-prefixed version of env vars (setenv (string-append "CROSS_" env-name) (filter-delimited-string env-val mingw-path?))))- '("CPLUS_INCLUDE_PATH" "LIBRARY_PATH" "C_INCLUDE_PATH"))))+ '("LIBRARY_PATH" "CPATH")))) (add-before 'build 'fix-target-detection (lambda _ ;; NSIS target detection is screwed up, manually

However, that does not work. Trying to build this fix results in the curiouserror that we encounter in the long-standing "important" issue #30756 (to beclear, this is an error while in the `build' phase of the nsis-x86_64 package,not mingw-w64):
In file included from /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/include/c++/bits/stl_algo.h:59:0, from /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/include/c++/algorithm:62, from Contrib/InstallOptions/InstallerOptions.cpp:23:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/include/c++/cstdlib:75:15: fatal error: stdlib.h: No such file or directory #include_next <stdlib.h> ^~~~~~~~~~compilation terminated.
For some context, here is the full environment-variables file for that failedbuild:
export CPATH="/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/include:/gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11/include:/gnu/store/l86azr7r3p5631wj3kk329jl1y1mpjgy-bzip2-1.0.6/include:/gnu/store/lbip9isk25isymvnb159l115xnacb5j8-xz-5.2.4/include:/gnu/store/6jdshxwdrad9mlhcqc9k0g24yw45rqf1-file-5.33/include:/gnu/store/2z9hsww76aag37p40671l9niq5pvvasx-gawk-5.0.1/include:/gnu/store/b5vpfzkr59bpgcsg1k9vvad9h5rwvpgk-make-4.2.1/include:/gnu/store/3hkdiscs4910r75njbrql10znxxn7chk-binutils-2.32/include:/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/include:/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/include:/gnu/store/7czrqpi0kwazras6pgyx0bhdn89pg0jl-linux-libre-headers-4.19.56/include"export CROSS_CPATH="/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-x86_64-6.0.0/include"export CROSS_LIBRARY_PATH="/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-x86_64-6.0.0/lib"export GUIX_LD_WRAPPER_ALLOW_IMPURITIES="no"export GUIX_LOCPATH="/gnu/store/mmqp1xqffn6qw6v88i627c2bpbq36fcy-glibc-utf8-locales-2.29/lib/locale"export HOME="/homeless-shelter"export LC_ALL="en_US.utf8"export LIBRARY_PATH="/gnu/store/xiiafbq3c78kxkgv5zr54zpb8r4jz5ii-scons-python2-3.0.4/lib:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/lib:/gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11/lib:/gnu/store/l86azr7r3p5631wj3kk329jl1y1mpjgy-bzip2-1.0.6/lib:/gnu/store/lbip9isk25isymvnb159l115xnacb5j8-xz-5.2.4/lib:/gnu/store/6jdshxwdrad9mlhcqc9k0g24yw45rqf1-file-5.33/lib:/gnu/store/2z9hsww76aag37p40671l9niq5pvvasx-gawk-5.0.1/lib:/gnu/store/3hkdiscs4910r75njbrql10znxxn7chk-binutils-2.32/lib:/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib:/gnu/store/qky1x5bb2jygy58bn6y95ygfsmpakf52-glibc-2.29-static/lib:/gnu/store/mmqp1xqffn6qw6v88i627c2bpbq36fcy-glibc-utf8-locales-2.29/lib"export NIX_BUILD_CORES="0"export NIX_BUILD_TOP="/tmp/guix-build-nsis-x86_64-3.04.drv-0"export NIX_STORE="/gnu/store"export OLDPWDexport PATH="/gnu/store/xiiafbq3c78kxkgv5zr54zpb8r4jz5ii-scons-python2-3.0.4/bin:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/bin:/gnu/store/9nspnmi8prly39p3xx4plvbk9dywhf4y-binutils-cross-x86_64-w64-mingw32-2.32/bin:/gnu/store/cnqpra8vr2l5fz00rr4yj4bp3hr00cfw-tar-1.32/bin:/gnu/store/py3k9zla9fj3z7430v4crqj5pyrsd3qj-gzip-1.10/bin:/gnu/store/l86azr7r3p5631wj3kk329jl1y1mpjgy-bzip2-1.0.6/bin:/gnu/store/lbip9isk25isymvnb159l115xnacb5j8-xz-5.2.4/bin:/gnu/store/6jdshxwdrad9mlhcqc9k0g24yw45rqf1-file-5.33/bin:/gnu/store/58sq8iabw3jkv0fvf95hd7sq2g4xcsnz-diffutils-3.7/bin:/gnu/store/v76scv4n63ip08g119rczh2mrw31zwpd-patch-2.7.6/bin:/gnu/store/g9d3wv1d68iflx57yp3mcp3k3sv8spsl-findutils-4.6.0/bin:/gnu/store/2z9hsww76aag37p40671l9niq5pvvasx-gawk-5.0.1/bin:/gnu/store/afmvfw1yhfal48n1kjq6bk6kcw8sc3db-sed-4.7/bin:/gnu/store/7iyvxhp2g3v3655zqwr6biz2h0lqv7pr-grep-3.3/bin:/gnu/store/9kzrrccpzl6i1sfwb0drb00gi2gwk0x0-coreutils-8.31/bin:/gnu/store/b5vpfzkr59bpgcsg1k9vvad9h5rwvpgk-make-4.2.1/bin:/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin:/gnu/store/nc5vlidpxbvngalng30nif8nb3j7gfy2-ld-wrapper-0/bin:/gnu/store/3hkdiscs4910r75njbrql10znxxn7chk-binutils-2.32/bin:/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/bin:/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/bin:/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/sbin"export PWD="/tmp/guix-build-nsis-x86_64-3.04.drv-0/nsis-3.04-src"export SHLVL="1"export SOURCE_DATE_EPOCH="1"export TEMP="/tmp/guix-build-nsis-x86_64-3.04.drv-0"export TEMPDIR="/tmp/guix-build-nsis-x86_64-3.04.drv-0"export TMP="/tmp/guix-build-nsis-x86_64-3.04.drv-0"export TMPDIR="/tmp/guix-build-nsis-x86_64-3.04.drv-0"export out="/gnu/store/wnjkbggyv1jgc2ld9yrissdsjqjvnim8-nsis-x86_64-3.04"
So, to get a better understanding of what was going on, I went into theenvironment, and ran:
$ x86_64-w64-mingw32-g++ -E -v -xc++ - < /dev/null > /dev/null
Which yielded:
Using built-in specs.COLLECT_GCC=x86_64-w64-mingw32-g++Target: x86_64-w64-mingw32Configured with:Thread model: win32gcc version 7.4.0 (GCC)COLLECT_GCC_OPTIONS='-E' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/libexec/gcc/x86_64-w64-mingw32/7.4.0/cc1plus -E -quiet -v -U_REENTRANT - -mtune=generic -march=x86-64ignoring nonexistent directory "/no-gcc-local-prefix/include"ignoring nonexistent directory "/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/../../../../x86_64-w64-mingw32/include"ignoring nonexistent directory "/mingw/include"#include "..." search starts here:#include <...> search starts here: /gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-x86_64-6.0.0/include /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/include/c++ /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/include/c++/x86_64-w64-mingw32 /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/include/c++/backward /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/include /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/include-fixedEnd of search list.COMPILER_PATH=/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/libexec/gcc/x86_64-w64-mingw32/7.4.0/:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/libexec/gcc/x86_64-w64-mingw32/7.4.0/:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/libexec/gcc/x86_64-w64-mingw32/:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/lib/gcc/x86_64-w64-mingw32/CROSS_LIBRARY_PATH=/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-x86_64-6.0.0/lib/:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/../../../../x86_64-w64-mingw32/lib/COLLECT_GCC_OPTIONS='-E' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
So if we were to look back at the error from before, it seems thatgcc-cross-x86_64-w64-mingw32-7.4.0/include/c++/cstdlib.h was trying to includethe file stdlib.h in directories listed AFTER it in the list of search paths,BUT stdlib.h actually resides in mingw-w64-x86_64-6.0.0/include, which is beforeit in the effective list of search paths.
Note that the reason mingw-w64-x86_64-6.0.0/include is in this list at all isbecause of the 'fix-env phase I added, which plucked it from CPATH and ploppedit into CROSS_CPATH.
I also took a look at Ubuntu's x86_64-w64-mingw32-g++ to see how they do it, andit would seem that mingw-w64-x86_64-6.0.0/include should be the last thing onthat list:
ignoring nonexistent directory "/usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/../../../../x86_64-w64-mingw32/sys-include"#include "..." search starts here:#include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include/c++ /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include/c++/x86_64-w64-mingw32 /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include/c++/backward /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include-fixed /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/../../../../x86_64-w64-mingw32/includeEnd of search list.
So now we know what to fix, but how? My naive first thought was to list all ofthe search paths in the order I wanted them in CROSS_CPATH, like so (pretend thenewlines didn't exist):
CROSS_CPATH=/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/include/c++:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/include/c++/x86_64-w64-mingw32:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/include/c++/backward:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/include:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/include-fixed:/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-x86_64-6.0.0/include
However, that doesn't work, what DID work was instead listing the order inCROSS_CPLUS_INCLUDE_PATH and leaving CROSS_CPATH alone, resulting in somethinglike:
CROSS_CPLUS_INCLUDE_PATH=/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/include/c++:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/include/c++/x86_64-w64-mingw32:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/include/c++/backward:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/include:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/include-fixed:/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-x86_64-6.0.0/includeCROSS_CPATH=/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-x86_64-6.0.0/include
Note that I did try unsetting CROSS_CPATH, which did not work either.Ultimately, this means that the final patch which works is the following:
diff --git a/gnu/packages/installers.scm b/gnu/packages/installers.scmindex c987254d61..794e9a758f 100644--- a/gnu/packages/installers.scm+++ b/gnu/packages/installers.scm@@ -92,7 +92,20 @@ ;; CROSS_-prefixed version of env vars (setenv (string-append "CROSS_" env-name) (filter-delimited-string env-val mingw-path?))))- '("CPLUS_INCLUDE_PATH" "LIBRARY_PATH" "C_INCLUDE_PATH"))))+ '("CPATH" "LIBRARY_PATH"))+ (setenv "CROSS_CPLUS_INCLUDE_PATH"+ (string-append+ (string-join+ (map+ (lambda (x) (string-append (assoc-ref %build-inputs "xgcc") x))+ `("/include/c++"+ ,(string-append "/include/c++" "/" ,triplet)+ "/include/c++/backward"+ "/lib/gcc/x86_64-w64-mingw32/7.4.0/include"+ "/lib/gcc/x86_64-w64-mingw32/7.4.0/include-fixed"))+ ":")+ ":"+ (getenv "CROSS_CPATH"))))) (add-before 'build 'fix-target-detection (lambda _ ;; NSIS target detection is screwed up, manually
I'd like some feedback on
1. Whether this hack is sane or not2. Does this apply to other packages suffering from the long-standing"important" issue #307563. Does this reveal something more fundamentally wrong with how we build oursearch paths in the first place that should be addressed4. How I might improve the readability of my final patch
Cheers,Carl Dongcontact@carldong.me"I fight for the users"
D
D
Danny Milosavljevic wrote on 18 Oct 2019 02:03
(name . Carl Dong)(address . contact@carldong.me)
20191018020344.78cbee48@scratchpost.org
Hi Carl,
On Thu, 17 Oct 2019 21:56:44 +0000Carl Dong <contact@carldong.me> wrote:
Toggle quote (4 lines)> Note that the reason mingw-w64-x86_64-6.0.0/include is in this list at all is> because of the 'fix-env phase I added, which plucked it from CPATH and plopped> it into CROSS_CPATH.
Yeah, I did the same in sunxi-tools--which was also broken after the core-updatesmerge, but had been working fine before.It's using an x86_64->ARM cross compiler.But just changing it to CROSS_CPATH works, there.
Toggle quote (3 lines)> 3. Does this reveal something more fundamentally wrong with how we build our> search paths in the first place that should be addressed
I think so. I can't figure out why Guix is not just setting up CROSS_CPATHon its own in the first place.gnu/packages/cross-base.scm DOES have a search-path specification for CROSS_CPATH.
Notes:
* CPATH is something like "-I", but CPATH applies after all command-line "-I"s.* C_INCLUDE_PATH, CPLUS_INCLUDE_PATH and OBJC_INCLUDE_PATH are something like"-isystem", but they apply after all command-line "-isystem"s.
Note that an empty (colon-separated) element in those environment variablesmeans "current working directory".
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Directory-Options.html:
Toggle quote (9 lines)>If a standard system include directory, or a directory specified with>-isystem, is also specified with -I, the -I option is ignored. The>directory is still searched but as a system directory at its normal>position in the system include chain. This is to ensure that GCC's>procedure to fix buggy system headers and the ordering for the>include_next directive are not inadvertently changed. If you really>need to change the search order for system directories, use the>-nostdinc and/or -isystem options.
Toggle quote (7 lines)>The lookup order is as follows:> For the quote form of the include directive, the directory of the current file is searched first.> For the quote form of the include directive, the directories specified by -iquote options are searched in LTR order.> Directories specified with -I options are scanned in left-to-right order.> Directories specified with -isystem options are scanned in left-to-right order.> Standard system directories are scanned[, except if -nostdinc[++] is specified].> Directories specified with -idirafter options are scanned in left-to-right order.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl2pAWAACgkQ5xo1VCwwuqVFYgf+KBfkOJd7YehA+OtQHDnI819hcMVMSRPLZmDyBIKVlxokjesni8/74l/cQaaPWUpGvHNgW4BgjH3WEujT8CvOdMXUnqkeJTD30F5l1dAw1x2NNs/rcXwHC25TV+cpwFyL/DymitEIt4JFfhGjb7SJ+sj/teUwn6mULMlC/I6SRwInIiRIMGv2AH054xDld8FLg1vHyh4+jTNjlIrlmd9oKEaDjqPQ9ljHNeWXbbUlJekm44ih+yMW+RVW36XAs1xfatAnP3TdxoDoqQY4Euz3T5bvv+OnfhRGA4aYTpf5XXITjyrATTR3A6v2MRO0bFSGBfbniZl6DzCsop9nmU8cMA===XI3H-----END PGP SIGNATURE-----

C
C
Carl Dong wrote on 18 Oct 2019 16:02
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
H5R52pYX-v7FYakGyXf-DjdVXYEMCTAR211IyaKX1lZ2haUGvm22ZfH8fRu1u8LWJPMCGhmUmvufVp43KseEbK69HVcAWfi0sKpuZkUEA4k=@carldong.me
Hi Danny,
Thank you so much for the links and quotes, I'm definitely going to refer backto them in the future and you probably saved me dozens of hours :-)
Toggle quote (5 lines)> I think so. I can't figure out why Guix is not just setting up CROSS_CPATH> on its own in the first place.> gnu/packages/cross-base.scm DOES have a search-path specification for> CROSS_CPATH.
Perhaps Ludovic can confirm this, but I believe the reason why Guix is notsetting up CROSS_CPATH is because it doesn't _know_ it's cross-compiling. Guixonly sets up CROSS_CPATH when we invoke on the command line with--target=x86_64-w64-mingw32 or something like that. I'm not exactly sure what aclean solution to this is, but I'd hope we can find one in the future.
I'm thinking that the reason why my final solution involved explicitly settingthe exact ordering in my CROSS_CPLUS_INCLUDE_PATH was because mingw-w64 isconsidered to be libc and that makes it special somehow. Not 100% sure though.
Cheers,Carl Dongcontact@carldong.me"I fight for the users"
D
D
Danny Milosavljevic wrote on 19 Oct 2019 14:53
(name . Carl Dong)(address . contact@carldong.me)
20191019145336.4fb5af37@scratchpost.org
Hi,
On Fri, 18 Oct 2019 14:02:33 +0000Carl Dong <contact@carldong.me> wrote:
Toggle quote (3 lines)> 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.
Ah, that makes a lot of sense! But the "cross-gcc" returns a cross compilerthat should know that we're cross-compiling (but it sets up SEARCH-PATHSwith CROSS_LIBRARY_PATH and CROSS_CPATH, but not NATIVE-SEARCH-PATHS. Hmm).
But the fundamental problem remains that guix host-side can't know whetherwe are cross compiling from this. It has its own cross-compiling supportat the toplevel, at the guix command line.
The following is only tangentially related to your issue, so maybe not souseful 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
(native-inputs `(("pkg-config" ,pkg-config) ("cross-gcc" , (xcross (cross-gcc "arm-linux-gnueabihf" #:xbinutils (cross-binutils "arm-linux-gnueabihf") #:libc (xcross (cross-libc "arm-linux-gnueabihf"))))))) ;("cross-libc" ,(xcross (cross-libc "arm-linux-gnueabihf"))) ; header files ("cross-libc-static" ,(xcross (cross-libc "arm-linux-gnueabihf")) "static") ("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 system inquestion and some that are supposed to run on the host (both are GNU systems).For convenience, I'm (and upstream are) trying to provide both in thederivation--I think because the tools can send a program via USB to the embeddedsystem.
So if you compile sunxi-tools on x86_64, you get host tools for x86_64 and targettools for ARM.
If you compile sunxi-tools on x86_64 for RISC-V, you get host tools forRISC-V and target tools for ARM.
So it basically has to override the "which cross compiler" setting later inthe compilation process.
The more I think about it the more I'm getting the feeling that I should stoptrying to fit a square peg into a round hole and just add an extra packagefor 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 :)
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl2rB1AACgkQ5xo1VCwwuqWpEQf7BYjRWTf6FxSmHJtWLtxqIQXHNcVuBMoygghLRcK+iQ+60l6deyHskjSoN0PRD36rIRswGr5QKcjXij6j/VS0K9yTUltfAVx03UiH7/SYpEfpfKnLTQGKeVVEJaqK7KaOiWP0xAuVrQCsO00QYlQctzBpex5T4Jc8ugCUM837byQAjjup6RZ708NidWTGIGGZrgOiy8T6yvzHWse/4EUJS8jQmAdk18zWzoyIP6VXOP0IAELcgLe443OGeaKw/hGmrj8W0mEjWOPEUHJMgNzo5tI3ESea7xUQgcITk6cKFdxDmD9S9SKrMQuxCmqmCGpa2iU3edhJ3bPcfWQM12wlQg===up/c-----END PGP SIGNATURE-----

?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send email to 37801@debbugs.gnu.org