[I expect this is more than just amd64-gcc related but that is all that ci.freebsd.org normally builds via a devel/*-gcc .] On 2018-Jun-29, at 10:38 AM, John Baldwin <jhb at freebsd.org> wrote: > On 6/28/18 7:54 PM, Mark Millard wrote: >> On 2018-Jun-28, at 6:04 PM, Mark Millard <marklmi at yahoo.com> wrote: >> >>> On 2018-Jun-28, at 5:39 PM, Mark Millard <marklmi at yahoo.com> wrote: >>> >>> . . . >>> Later below expand the failing and previoly good commands, one >>> option per line. The summary of the distinction in content is >>> a one line difference, the working example ( -r335773 )had the >>> option: >>> >>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>> >>> but the failing one did not. Working ( -r335773 ) is shown first. >>> >>> --- catrigl.o --- >>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc >>> -DCOMPAT_32BIT >>> -march=i686 >>> -mmmx >>> -msse >>> -msse2 >>> -m32 >>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>> -B/usr/local/x86_64-unknown-freebsd11.1/bin/ >>> -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>> -O2 >>> -pipe >>> -I/workspace/src/lib/msun/x86 >>> -I/workspace/src/lib/msun/ld80 >>> -I/workspace/src/lib/msun/i387 >>> -I/workspace/src/lib/msun/src >>> -I/workspace/src/lib/libc/include >>> -I/workspace/src/lib/libc/i386 >>> . . . >>> >>> --- catrigl.o --- >>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc >>> -DCOMPAT_32BIT >>> -march=i686 >>> -mmmx >>> -msse >>> -msse2 >>> -m32 >>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>> -B/usr/local/x86_64-unknown-freebsd11.1/bin/ >>> -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>> -O2 >>> -pipe >>> -I/workspace/src/lib/msun/x86 >>> -I/workspace/src/lib/msun/ld80 >>> -I/workspace/src/lib/msun/i387 >>> -I/workspace/src/lib/msun/src >>> -I/workspace/src/lib/libc/include >>> -I/workspace/src/lib/libc/i386 >>> . . . >> >> >> For the report: >> >>> The xtoolchain GCC packages have not required these flags since ports >>> commits r465416 and r466701 >> >> Looking at https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText >> there is: >> >>> Updating FreeBSD repository catalogue... >>> FreeBSD repository is up to date. >>> All repositories are up to date. >>> The following 6 package(s) will be affected (of 0 checked): >>> >>> New packages to be INSTALLED: >>> amd64-xtoolchain-gcc: 0.4_1 >>> amd64-gcc: 6.4.0 >>> mpfr: 4.0.1 >>> gmp: 6.1.2 >>> mpc: 1.1.0_1 >>> amd64-binutils: 2.30_3,1 >> >> and amd64-gcc being 6.4.0 (via powerpc64-gcc) is from -r466834 >> (via looking up in https://svnweb.freebsd.org/ports/head/devel/ ). >> >> This indicates that -r465416 and -r466701 did not cause: >> >> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >> >> to lead to include files being looked up in: >> >> /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >> >> Thus there appears to still be a need for: >> >> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >> >> unless more is done to the devel/*-gcc to make them look >> in that additional place automatically (based on --sysroot). > > --sysroot does work, and you can verify it by doing the following: > > % touch empty.c > % x86_64-unknown-freebsd11.2-gcc -c -v empty.c > Using built-in specs. > COLLECT_GCC=x86_64-unknown-freebsd11.2-gcc > Target: x86_64-unknown-freebsd11.2 > ... > ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed" > ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-unknown-freebsd11.2/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include > /usr/include > End of search list. > ... > % x86_64-unknown-freebsd11.2-gcc -c -v empty.c --sysroot=/foo > Using built-in specs. > COLLECT_GCC=x86_64-unknown-freebsd11.2-gcc > Target: x86_64-unknown-freebsd11.2 > ... > ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed" > ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-unknown-freebsd11.2/include" > ignoring nonexistent directory "/foo/usr/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include > End of search list. > > I will see if I can reproduce the failure locally. The: ignoring nonexistent directory "/foo/usr/include" means that the order of the search alternatives was not shown ("search starts here"). That is what I expect is different. It will take a while before I'll have a build from either before or after the change to show a search order with. (And longer to have both for comparison.) My context is freebsd12.0 . My buildworld buildkernel context has: # more ~/src.configs/make.conf CFLAGS.gcc+= -v so my script file for a build is very explicit about the order. I'll be starting from # uname -apKU FreeBSD FBSDUSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r335245M amd64 amd64 1200069 1200069 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)Received on Fri Jun 29 2018 - 19:58:11 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC