Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Aug 2016 10:59:33 -0700
From:      Bryan Drewery <bdrewery@FreeBSD.org>
To:        Li-Wen Hsu <lwhsu@FreeBSD.org>
Cc:        Dimitry Andric <dim@FreeBSD.org>, Craig Rodrigues <rodrigc@freebsd.org>, "jenkins-admin@freebsd.org" <jenkins-admin@freebsd.org>, "freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org>, jmmv@FreeBSD.org
Subject:   Re: Jenkins build is still unstable: FreeBSD_HEAD #564
Message-ID:  <790b2e2d-a240-b17d-ff0d-dac16194b57e@FreeBSD.org>
In-Reply-To: <20160829175818.GB10263@FreeBSD.cs.nctu.edu.tw>
References:  <CAG=rPVdZp171Egp=OHWDc3qCgcJDE3HQ0rv-j=i%2BO1LHcfH%2BJQ@mail.gmail.com> <CFA236ED-7DE0-4BE1-B944-52284E2FB6E0@FreeBSD.org> <6E443BB8-0269-4812-A2F4-40AA303E69C6@FreeBSD.org> <CAG=rPVdfgoF0mts-edHATUaefD7YuGtNu5ZTJOa8efUn2W4QuA@mail.gmail.com> <8058052E-A09A-403E-828A-74B51ED4BBF4@FreeBSD.org> <20160829163911.GA51650@FreeBSD.cs.nctu.edu.tw> <E73154DF-6A88-457D-B1FF-6B7F7610C37F@FreeBSD.org> <4b8980f0-1a90-40d7-45b3-9569b321d1c6@FreeBSD.org> <20160829175247.GA10263@FreeBSD.cs.nctu.edu.tw> <153107ba-094b-3eec-165b-a10080d6d26b@FreeBSD.org> <20160829175818.GB10263@FreeBSD.cs.nctu.edu.tw>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--vIEsnQpMdJQAEpSB0mQuvOeaxGspW7Imu
Content-Type: multipart/mixed; boundary="G2lvAijFNxlKJfBhV3qRVPArtHqj0LV5b"
From: Bryan Drewery <bdrewery@FreeBSD.org>
To: Li-Wen Hsu <lwhsu@FreeBSD.org>
Cc: Dimitry Andric <dim@FreeBSD.org>, Craig Rodrigues <rodrigc@freebsd.org>,
 "jenkins-admin@freebsd.org" <jenkins-admin@freebsd.org>,
 "freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org>, jmmv@FreeBSD.org
Message-ID: <790b2e2d-a240-b17d-ff0d-dac16194b57e@FreeBSD.org>
Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD #564
References: <CAG=rPVdZp171Egp=OHWDc3qCgcJDE3HQ0rv-j=i+O1LHcfH+JQ@mail.gmail.com>
 <CFA236ED-7DE0-4BE1-B944-52284E2FB6E0@FreeBSD.org>
 <6E443BB8-0269-4812-A2F4-40AA303E69C6@FreeBSD.org>
 <CAG=rPVdfgoF0mts-edHATUaefD7YuGtNu5ZTJOa8efUn2W4QuA@mail.gmail.com>
 <8058052E-A09A-403E-828A-74B51ED4BBF4@FreeBSD.org>
 <20160829163911.GA51650@FreeBSD.cs.nctu.edu.tw>
 <E73154DF-6A88-457D-B1FF-6B7F7610C37F@FreeBSD.org>
 <4b8980f0-1a90-40d7-45b3-9569b321d1c6@FreeBSD.org>
 <20160829175247.GA10263@FreeBSD.cs.nctu.edu.tw>
 <153107ba-094b-3eec-165b-a10080d6d26b@FreeBSD.org>
 <20160829175818.GB10263@FreeBSD.cs.nctu.edu.tw>
In-Reply-To: <20160829175818.GB10263@FreeBSD.cs.nctu.edu.tw>

--G2lvAijFNxlKJfBhV3qRVPArtHqj0LV5b
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 8/29/2016 10:58 AM, Li-Wen Hsu wrote:
> On Mon, Aug 29, 2016 at 10:54:04 -0700, Bryan Drewery wrote:
>> On 8/29/2016 10:52 AM, Li-Wen Hsu wrote:
>>> I guess the quickest way is boot that VM, cd to
>>> /usr/tests/lib/atf/libatf-c++ and run `kyua test atf_c++_test`
>>> However I am not sure this provides enough information because stuff
>>> under /usr/tests/lib/atf/libatf-c++ are all binary files.
>>>
>>> FWIW, I would like to know, should these -target, --sysroot and -B fl=
ages be
>>> given when compiling a normal program in a normal time?  In this test=

>>> case, kyua just wanted to compile test.cpp which includes sstream, it=
's
>>> not during buildworld/buildkernel time, so files under /usr/obj
>>> should not be used.
>>
>> The flags are only passed in buildworld which uses a sysroot.  A direc=
t
>> cd dir && make, will not use them.
>=20
> Does this mean that kyua should not include these flages while running
> tests ("test" here is "test to compile a .cpp file")?  If so, we might
> need to find out what affects kyua adding these flags.
>=20
>=20

They should not be present when running tests.  It sounds like the flags
are bleeding in during buildworld and getting stored permanently
somewhere as the place to look for headers rather than /usr/include.

>=20
>=20
>=20
>>> On Mon, Aug 29, 2016 at 10:31:26 -0700, Bryan Drewery wrote:
>>>> This thread is hard to follow. The changes I made shouldn't break
>>>> anything since it's just now acting like an external compiler.
>>>>
>>>> Where is the error so I can debug it?
>>>>
>>>> On 8/29/2016 9:50 AM, Dimitry Andric wrote:
>>>>> Yes, I've also seen the --sysroot options being added recently.  I'=
m reasonably sure that this is the cause of the error.  Bryan did most of=
 the restructuring for external toolchains, which also adds the --sysroot=
 option.
>>>>>
>>>>> Is there an usr/include/c++/v1 under the --sysroot?
>>>>>
>>>>> -Dimitry
>>>>>
>>>>>> On 29 Aug 2016, at 18:39, Li-Wen Hsu <lwhsu@FreeBSD.org> wrote:
>>>>>>
>>>>>> Dimitry, are you talking about case lib.atf.libatf-c++.atf_c++_tes=
t.include ?
>>>>>>
>>>>>> I happen to have a r304986 VM here:
>>>>>>
>>>>>> https://people.freebsd.org/~lwhsu/tmp/disk-test.img.xz
>>>>>>
>>>>>> (it starts kyua test in /etc/rc.local, just use ctrl-c to interrup=
t it)
>>>>>>
>>>>>> And there is a /usr/include/c++/v1 directory with sstream in it.
>>>>>>
>>>>>>
>>>>>> BTW, I am not sure removing -I/usr/include is the right solution, =
 I
>>>>>> think this case is checking for "normal" compiling would work, not=

>>>>>> during buildworld.  When this case was passing, it uses following
>>>>>> command:
>>>>>>
>>>>>> c++ -O2 -pipe -DHAVE_CONFIG_H -I/usr/include -Wall -Werror -o test=
=2Eo -c test.cpp
>>>>>>
>>>>>> and now it uses:
>>>>>>
>>>>>> c++ -target x86_64-unknown-freebsd12.0 --sysroot=3D/usr/obj/usr/sr=
c/tmp -B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -DHAVE_CONFIG_H -I/usr/inc=
lude -Wall -Werror -o test.o -c test.cpp
>>>>>>
>>>>>> This changed between r304555 and r304698.
>>>>>>
>>>>>>
>>>>>> Also, does anyone know where is "-I/usr/include" coming from?  Is =
this
>>>>>> one?
>>>>>> https://svnweb.freebsd.org/base/head/contrib/atf/atf-c%2B%2B/detai=
l/test_helpers.cpp?view=3Dmarkup#l56
>>>>>>
>>>>>>
>>>>>> Li-Wen
>>>>>>
>>>>>> On Mon, Aug 29, 2016 at 16:02:42 +0200, Dimitry Andric wrote:
>>>>>>> Do you have an /usr/include/c++/v1 directory?  And is there a fil=
e called "sstream" in it?
>>>>>>>
>>>>>>> If it is there, I think the problem is due to the -I/usr/include =
option in the command line for the test program.  If you remove that, I t=
hink the compilation will work correctly.
>>>>>>>
>>>>>>> -Dimitry
>>>>>>>
>>>>>>>> On 29 Aug 2016, at 14:55, Craig Rodrigues <rodrigc@freebsd.org> =
wrote:
>>>>>>>>
>>>>>>>> Dimitry,
>>>>>>>>
>>>>>>>> During the Jenkins job, I use installworld/installkernel to buil=
d a fully bootable bhyve virtual machine.
>>>>>>>> After the virtual machine boots, ssh into it, and do:
>>>>>>>>
>>>>>>>> cd /usr/tests
>>>>>>>> kyua test
>>>>>>>> kyua report --verbose
>>>>>>>>
>>>>>>>>
>>>>>>>> So I am suspecting that maybe something didn't get installed pro=
perly?
>>>>>>>> --
>>>>>>>> Craig
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Aug 29, 2016 at 4:13 AM, Dimitry Andric <dim@freebsd.org=
> wrote:
>>>>>>>> I just found the separate "test results" link in Jenkins.  As fa=
r as I can see, one of those failing tests is run as:
>>>>>>>>
>>>>>>>> c++ -target x86_64-unknown-freebsd12.0 --sysroot=3D/builds/works=
pace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp -B/builds/wor=
kspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/usr/bin -O2=
 -pipe -DHAVE_CONFIG_H -I/usr/include -Wall -Werror -o test.o -c test.cpp=

>>>>>>>>
>>>>>>>> So are the libc++ headers installed in the /builds/workspace/Fre=
eBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp sysroot?  The compile=
r error message appears to indicate it is getting its headers from /usr/i=
nclude instead.
>>>>>>>>
>>>>>>>> I can't look on the actual test system, but my guess would be th=
at either the --sysroot flag is incorrect, or the libc++ headers are not =
correctly installed on the target system.
>>>>>>>>
>>>>>>>> -Dimitry
>>>>>>>>
>>>>>>>>> On 29 Aug 2016, at 12:56, Dimitry Andric <dim@FreeBSD.org> wrot=
e:
>>>>>>>>>
>>>>>>>>> Hi Craig,
>>>>>>>>>
>>>>>>>>> I find it very hard to parse these extremely verbose logs.  Can=
 you point out the location and contents of the exact error you are seein=
g?
>>>>>>>>>
>>>>>>>>> -Dimitry
>>>>>>>>>
>>>>>>>>>> On 29 Aug 2016, at 08:59, Craig Rodrigues <rodrigc@FreeBSD.org=
> wrote:
>>>>>>>>>>
>>>>>>>>>> Dimitry,
>>>>>>>>>>
>>>>>>>>>> Can you take a look at this?
>>>>>>>>>> I'm not sure why, but after recent changes, one of the tests i=
s
>>>>>>>>>> complaining that the C++ header <sstream> is missing.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Craig
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sun, Aug 28, 2016 at 11:11 PM, <jenkins-admin@freebsd.org> =
wrote:
>>>>>>>>>> See <https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/564/>;
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Li-Wen Hsu <lwhsu@FreeBSD.org>
>>>>>> https://lwhsu.org
>>>>>
>>>>
>>>>
>>>> --=20
>>>> Regards,
>>>> Bryan Drewery
>>>>
>>>
>>>
>>>
>>>
>>
>>
>> --=20
>> Regards,
>> Bryan Drewery
>>
>=20
>=20
>=20
>=20


--=20
Regards,
Bryan Drewery


--G2lvAijFNxlKJfBhV3qRVPArtHqj0LV5b--

--vIEsnQpMdJQAEpSB0mQuvOeaxGspW7Imu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJXxHgFAAoJEDXXcbtuRpfPX3sH/RsF4VRZbUOB1tJmb4dkCQvP
kKTi/6fWt64nrjEqSKcvxGsCFjbkUV54N0X1z9hwmdLeYYNWh0ktFHJ2pHZpMluS
h9CImRHGnDn+vDQ1iWUQ7STpRGLFqrkAarWBuNOO+8WcmicT6P7VMUqGwfY+h0SO
FGZbmnFLUJ1jHu6kTVHndQJMmEr43nL66saMeQkq1umEkwc0ddTWk143EOUzdg73
ujaSh76da9vCM5TbaQ/HP/ZaW3PnddnqKqb3v/QaABfDwS7KHYb3O9JkZleswMnY
+arL1o7svL44XRqAEEuDx86cYt9lB6QHUdJW8+FREqUVdPco6G5eh8gGmGiJnR0=
=e7r2
-----END PGP SIGNATURE-----

--vIEsnQpMdJQAEpSB0mQuvOeaxGspW7Imu--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?790b2e2d-a240-b17d-ff0d-dac16194b57e>