Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Jun 2018 14:37:49 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Bryan Drewery <bdrewery@FreeBSD.org>, svn-src-head@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
Message-ID:  <003509F0-F2F4-4A43-82FE-3F6FC23D19D4@yahoo.com>
In-Reply-To: <72081b02-cf23-82ec-32df-7f5793c35f57@FreeBSD.org>
References:  <00D1127A-1F0E-4E0E-B86C-1C5AA5B2E085@yahoo.com> <CF0230A1-1384-4F0F-A96A-5AB555FD17AC@yahoo.com> <7A845F2C-C994-4828-823D-33A97B7B6EB0@yahoo.com> <72081b02-cf23-82ec-32df-7f5793c35f57@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
[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:
>>=20
>>> On 2018-Jun-28, at 5:39 PM, Mark Millard <marklmi at yahoo.com> =
wrote:
>>>=20
>>> . . .
>>> 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:
>>>=20
>>> -isystem =
/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
>>>=20
>>> but the failing one did not. Working ( -r335773 ) is shown first.
>>>=20
>>> --- catrigl.o ---
>>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc
>>> -DCOMPAT_32BIT
>>> -march=3Di686
>>> -mmmx
>>> -msse
>>> -msse2
>>> -m32
>>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32
>>> --sysroot=3D/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
>>> . . .
>>>=20
>>> --- catrigl.o ---
>>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc
>>> -DCOMPAT_32BIT
>>> -march=3Di686
>>> -mmmx
>>> -msse
>>> -msse2
>>> -m32
>>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32
>>> --sysroot=3D/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=20
>>> -I/workspace/src/lib/libc/i386
>>> . . .
>>=20
>>=20
>> For the report:
>>=20
>>> The xtoolchain GCC packages have not required these flags since =
ports
>>>  commits r465416 and r466701
>>=20
>> Looking at =
https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText
>> there is:
>>=20
>>> 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):
>>>=20
>>> 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
>>=20
>> and amd64-gcc being 6.4.0 (via powerpc64-gcc) is from -r466834
>> (via looking up in https://svnweb.freebsd.org/ports/head/devel/ ).
>>=20
>> This indicates that -r465416 and -r466701 did not cause:
>>=20
>> --sysroot=3D/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp
>>=20
>> to lead to include files being looked up in:
>>=20
>> /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
>>=20
>> Thus there appears to still be a need for:
>>=20
>> -isystem =
/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
>>=20
>> unless more is done to the devel/*-gcc to make them look
>> in that additional place automatically (based on --sysroot).
>=20
> --sysroot does work, and you can verify it by doing the following:
>=20
> % touch empty.c
> % x86_64-unknown-freebsd11.2-gcc -c -v empty.c
> Using built-in specs.
> COLLECT_GCC=3Dx86_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-un=
known-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=3D/foo
> Using built-in specs.
> COLLECT_GCC=3Dx86_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-un=
known-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.
>=20
> 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=20
CFLAGS.gcc+=3D -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


=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?003509F0-F2F4-4A43-82FE-3F6FC23D19D4>