On 2018-Jun-29, at 2:37 PM, Mark Millard <marklmi at yahoo.com> wrote: > [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 > Here is what head -r335245 got for my build . . . /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/lib/msun/catrigl.o.meta shows: ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include-fixed" ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/../../../../x86_64-unknown-freebsd12.0/include" ignoring duplicate directory "/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include" #include "..." search starts here: #include <...> search starts here: /usr/src/lib/msun/x86 /usr/src/lib/msun/ld80 /usr/src/lib/msun/i387 /usr/src/lib/msun/src /usr/src/lib/libc/include /usr/src/lib/libc/i386 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include End of search list. It will be some time before I have an attempted build of -r335782 or later to compare such with. But the above found FreeBSD's: # ls -lT /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/float.h lrwxr-xr-x 1 root wheel 15 Jun 29 16:27:34 2018 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/float.h -> machine/float.h # ls -lT /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/machine/float.h -rwxr-xr-x 1 root wheel 151 Nov 3 02:27:25 2016 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/machine/float.h instead of: # ls -lT /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/float.h -rw-r--r-- 1 root wheel 8729 May 26 05:05:37 2018 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/float.h === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)Received on Fri Jun 29 2018 - 23:02:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC