Date: Wed, 31 Aug 2016 17:21:48 -0700 From: "Ngie Cooper (yaneurabeya)" <yaneurabeya@gmail.com> To: Bryan Drewery <bdrewery@FreeBSD.org> Cc: Li-Wen Hsu <lwhsu@FreeBSD.org>, "jenkins-admin@freebsd.org" <jenkins-admin@freebsd.org>, "freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org>, Dimitry Andric <dim@FreeBSD.org> Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD #564 Message-ID: <8130400D-BD67-446D-903E-A6242D13908E@gmail.com> In-Reply-To: <CC62FF40-2696-4A51-B93D-57611FB1FA8D@gmail.com> References: <1491374121.44.1472440150670.JavaMail.jenkins@jenkins-9.freebsd.org> <166099893.51.1472451061454.JavaMail.jenkins@jenkins-9.freebsd.org> <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> <CAA41D00-2451-42EC-B9FD-3E31F42F9CF6@gmail.com> <31f11ba3-ca29-0f85-f1c1-6a3cd467bb57@FreeBSD.org> <67E84707-3267-49F3-8DB6-13CBD05B1690@gmail.com> <B014DD06-4BB2-4503-8908-C78EFEE0FCA2@gmail.com> <3B60A57F-778C-4E7C-B081-098C0F6E92D2@gmail.com> <F144F428-A8B6-4E95-999E-D20B0A7B62C2@gmail.com> <5485945b-6539-5ed0-c089-5537d6bd70a9@FreeBSD.org> <BA574AB2-1B02-4F04-BBA2-A3BCB90F3DB3@gmail.com> <CC62FF40-2696-4A51-B93D-57611FB1FA8D@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_237DBF5D-3D3A-48FB-848A-EF88CA35C187 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 31, 2016, at 16:39, Ngie Cooper (yaneurabeya) = <yaneurabeya@gmail.com> wrote: >=20 >>=20 >> On Aug 30, 2016, at 01:45, Ngie Cooper (yaneurabeya) = <yaneurabeya@gmail.com> wrote: >>=20 >>=20 >>> On Aug 29, 2016, at 11:20, Bryan Drewery <bdrewery@FreeBSD.org> = wrote: >>=20 >> =E2=80=A6 >>=20 >>> Trust me, you're wasting your time, this is not the problem. If it = were >>> then _nothing_ would compile from the /usr/bin/cc compiler. It's = only a >>> problem with running the ATF tests which means it is likely storing = the >>> flags it is built with somewhere and reusing them. >>=20 >> Well, that was part of the problem, but it seems that clang is indeed = caching -sysroot when running the _everything phase of buildworld. =46rom = https://jenkins.freebsd.org/job/FreeBSD_HEAD/571/consoleText : >>=20 >> 50585 --- AnalysisDeclContext.o --- >> 50586 c++ -O2 -pipe = -I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclanganalysis/../../../c= ontrib/llvm/include = -I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclanganalysis/../../../c= ontrib/llvm/ tools/clang/include = -I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclanganalysis/../../../c= ontrib/llvm/tools/clang/lib/Analysis -I. = -I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclanganaly = sis/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX = -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS = -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknow = n-freebsd12.0\" -DLLVM_HOST_TRIPLE=3D\"x86_64-unknown-freebsd12.0\" = -DDEFAULT_SYSROOT=3D\"/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/= FreeBSD_HEAD/src/tmp\" -MD -MF.depend.AnalysisDeclContext .o = -MTAnalysisDeclContext.o -Qunused-arguments = -I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp= /legacy/usr/include -std=3Dc++11 -fno-exceptions -fno-rtti = -stdlib=3Dlibc++ - Wno-c++11-extensions -c = /builds/workspace/FreeBSD_HEAD/src/lib/clang/libclanganalysis/../../../con= trib/llvm/tools/clang/lib/Analysis/AnalysisDeclContext.cpp -o = AnalysisDeclContext.o >>=20 >> The reason why =E2=80=9Cno one=E2=80=9D has seen this probably is = this is that is: >>=20 >> - not default (using an inaccessible ${WORLDTMP} from an install = image; path isn=E2=80=99t standard). >> - ^/stable/11 is still a fairly fresh branch and the number of people = testing on ^/head is likely smaller than the ^/stable/... branches. >=20 > I just proved my theory wrong by doing the following: >=20 > $ sudo chown /obj /wnw > $ sudo chown ngie /obj > $ env MAKEOBJDIRPREFIX=3D/obj NO_CLEAN=3D1 script /tmp/bw make = buildworld -j4 > $ sudo make installworld DESTDIR=3D/wnw > $ sudo chroot /wnw /bin/sh > # cat <<EOF > hello_world.c > #include <stdio.h> > int main(void) { > printf("hello world\n=E2=80=9D); > return 0; > } > EOF > # cc -o hello_world hello_world.c > # ./hello_world > hello world >=20 > I did however prove that there=E2=80=99s a bug still in the tests by = doing what I did above: >=20 > # kyua report > =3D=3D=3D> Failed tests > libatf-c++/atf_c++_test:include -> failed: Header check failed; = atf-c++.hpp is not self-contained [0.042s] > libatf-c++/macros_test:use -> failed: Build of macros_hpp_test.cpp = failed; some macros in atf-c++/macros.hpp are broken [0.030s] > =3D=3D=3D> Summary > Results read from = /root/.kyua/store/results.usr_tests_lib_atf.20160831-233801-403911.db > Test cases: 328 total, 0 skipped, 0 expected failures, 0 broken, 2 = failed > Total time: 7.023s > # kyua debug libatf-c++/atf_c++_test:include >> c++ -target x86_64-unknown-freebsd12.0 --sysroot=3D/obj/mnt/tmp = -B/obj/mnt/tmp/usr/bin -O2 -O2 -DHAVE_CONFIG_H -O2 -I/usr/include -Wall = -Werror -o test.o -c test.cpp > In file included from test.cpp:1: > In file included from /usr/include/atf-c++.hpp:29: > /usr/include/atf-c++/macros.hpp:29:10: fatal error: 'sstream' file not = found > #include <sstream> > ^ > 1 error generated. > c++ failed with exit code 1 > Files left in work directory after failure: test.cpp > libatf-c++/atf_c++_test:include -> failed: Header check failed; = atf-c++.hpp is not self-contained >=20 > Working on a fix right now. Ok =E2=80=94 here=E2=80=99s the problem: # strings /usr/lib/libprivateatf-c.so.1 | grep /obj cc -target x86_64-unknown-freebsd12.0 --sysroot=3D/obj/mnt/tmp = -B/obj/mnt/tmp/usr/bin cpp -target x86_64-unknown-freebsd12.0 --sysroot=3D/obj/mnt/tmp = -B/obj/mnt/tmp/usr/bin c++ -target x86_64-unknown-freebsd12.0 --sysroot=3D/obj/mnt/tmp = -B/obj/mnt/tmp/usr/bin Somehow the strings are getting put into libatf-c.so.1 . Getting much = closer. Thanks, -Ngie --Apple-Mail=_237DBF5D-3D3A-48FB-848A-EF88CA35C187 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXx3ScAAoJEPWDqSZpMIYV6iwQAK0FqbTsMl8hoSzwJaoLXoWn +4/p3CNdOmWUXj4mM3F5Dmi+fsNz5iAAci3WZcVBBOya1xNNZi8OPhD1CXIo8TTQ hwrmbDFK2gaT4I8M+ky3jQUCh7sQK24z1LouTd+k9WrjpiFfWDP7Lc7RggfMst8I fdD06ExBbqILoYVmUUmvXDENSwt7h2OXth36qfUf+/DRtN0SQ/WVfL7VMfAqDCZq 0CeHx3eTARtmfFy7XfqHDOBEq9RVIpe0ZUQZSJ/TmiKGtEayEw9QdwSq7fRhhRZf abbLSuBbaQaTAdjfIjCok/VfFBLpfUms1kfJRa6vWwzu0C/v26uCFhDkDQA4YoDJ xxjYHs7Bsk4wjD8trwwzCwm53eLHrCGKMpfp0HF/s/bKNc54Vfx0tGbaiByoFJhp Wi1CYMumHf8jTccG55uoKvnhUM0OdoPdIQjuYiYK5UHoxRAoubgbs+3tp1lHwJUi fJu9TmRAack0/lZmKnxV/7UKm+RflZkr1Q3o+lgAQpKOoJhcqgDe/CGi58qICMpZ 8XQiqU5683vguJRtarSnTA3xd0QiDRWgTi/W7DGMwSnerMuDkqmLa1H0Z1Axf2PQ 1dD83aC6RPXxBZkF+cnGvZLZ8bPQfnlxbO3ZuFvrgWUjw2soIkH8PAd9TQ1c7YHY v9XaxNixqkY/n3uoUmmE =gem2 -----END PGP SIGNATURE----- --Apple-Mail=_237DBF5D-3D3A-48FB-848A-EF88CA35C187--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8130400D-BD67-446D-903E-A6242D13908E>