Re: External toolchain support broken for devel/llvm38 but not devel/llvm37

On Tue, Aug 30, 2016 at 02:50:03PM -0700, Matthew Macy wrote:
> 
> 
> 
>  ---- On Tue, 30 Aug 2016 14:08:41 -0700 Brooks Davis <brooks_at_freebsd.org> wrote ---- 
>  > On Mon, Aug 29, 2016 at 08:12:08PM -0700, Matthew Macy wrote: 
>  > > It looks like there is something broken with the devel/llvm38 port or external toolchain support has regressed: 
>  > >  
>  > >  
>  > > This works: 
>  > > make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s 
>  > >  
>  > > This fails: 
>  > >  make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s 
>  > >  
>  > > with: 
>  > >  
>  > > /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld: /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a: No such file: No such file or directory 
>  > > clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation) 
>  >  
>  > I've fixed the install problem.  I'm rather confused about why clang 
>  > would try to link with sanitizer libraries when building source.  That's 
>  > certainly not default behavior. 
>  
> Thanks for the extremely prompt response to both issues. I haven't figured out why svn has problems but the libc/tests failure can be traced back to the following commit:
> 
> commit 3d2a537705eca33db3c523f4f92290d382aa7ab1
> Author: ngie <ngie_at_FreeBSD.org>
> Date:   Fri Jan 2 05:40:02 2015 +0000
> 
>     Don't install h_raw if dealing with clang 3.5.0+ to unbreak the tests2 Jenkins
>     job
>     
>     The h_raw application doesn't do proper bounds checking without the option
>     being supplied via the build, which means that it doesn't throw signals and
>     fail as expected
>     
>     PR: 196430
>     X-MFC with: r276479
> 
> diff --git a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
> index 04adc67..362178f 100755
> --- a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
> +++ b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
> _at__at_ -360,6 +360,9 _at__at_ raw_head()
>  raw_body()
>  {
>         prog="$(atf_get_srcdir)/h_raw"
> +       # Begin FreeBSD
> +       [ -x $prog ] || atf_skip "$prog is missing; skipping testcase"
> +       # End FreeBSD
>  
>         h_pass "$prog 9"
>         # Begin FreeBSD
> diff --git a/lib/libc/tests/ssp/Makefile b/lib/libc/tests/ssp/Makefile
> index 1649cc2..7bc8660 100644
> --- a/lib/libc/tests/ssp/Makefile
> +++ b/lib/libc/tests/ssp/Makefile
> _at__at_ -9,10 +9,7 _at__at_ WARNS?=        2
>  
>  CFLAGS.h_raw+= -fstack-protector-all -Wstack-protector
>  .if ${COMPILER_TYPE} == "clang"
> -# Disable -fsanitize=bounds until runtime support is done for clang 3.5.0.
> -.if ${COMPILER_VERSION} < 30500
>  CFLAGS.h_raw+= -fsanitize=bounds
> -.endif

Thanks for hunting this down.

There's no strong reason to assume that a given clang has sanitizers
available.  In the current build system, you need a clang tree to build
the sanitizers, but the build process is separate.  If we're going to
enable sanitizers in tests, we need to do so conditionally so we don't
break the tests on non-x86 systems and so compiler installs don't need
to provide them.

-- Brooks