Jenkins build is still unstable: FreeBSD_HEAD #564

[Ngie Cooper (yaneurabeya)]

> On Aug 30, 2016, at 01:45, Ngie Cooper (yaneurabeya) <yaneurabeya at gmail.com> wrote:
> 
> 
>> On Aug 29, 2016, at 11:20, Bryan Drewery <bdrewery at FreeBSD.org> wrote:
> 
> …
> 
>> 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.
> 
> Well, that was part of the problem, but it seems that clang is indeed caching -sysroot when running the _everything phase of buildworld. From https://jenkins.freebsd.org/job/FreeBSD_HEAD/571/consoleText :
> 
> 50585 --- AnalysisDeclContext.o ---
> 50586 c++  -O2 -pipe -I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclanganalysis/../../../contrib/llvm/include -I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclanganalysis/../../../contrib/llvm/       tools/clang/include -I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclanganalysis/../../../contrib/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=\"x86_64-unknow       n-freebsd12.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=\"/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=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -       Wno-c++11-extensions  -c /builds/workspace/FreeBSD_HEAD/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/AnalysisDeclContext.cpp -o AnalysisDeclContext.o
> 
> The reason why “no one” has seen this probably is this is that is:
> 
> - not default (using an inaccessible ${WORLDTMP} from an install image; path isn’t standard).
> - ^/stable/11 is still a fairly fresh branch and the number of people testing on ^/head is likely smaller than the ^/stable/... branches.

I just proved my theory wrong by doing the following:

$ sudo chown /obj /wnw
$ sudo chown ngie /obj
$ env MAKEOBJDIRPREFIX=/obj NO_CLEAN=1 script /tmp/bw make buildworld -j4
$ sudo make installworld DESTDIR=/wnw
$ sudo chroot /wnw /bin/sh
# cat <<EOF > hello_world.c
#include <stdio.h>
int main(void) {
printf("hello world\n”);
return 0;
}
EOF
# cc -o hello_world hello_world.c
# ./hello_world
hello world

I did however prove that there’s a bug still in the tests by doing what I did above:

# kyua report
===> 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]
===> 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=/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

Working on a fix right now.

Thanks,
-Ngie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-testing/attachments/20160831/7e6cf6a0/attachment.sig>