Bug 206074 - [exp-run] Update clang in base to 3.8.0-r256945 (snapshot)
Summary: [exp-run] Update clang in base to 3.8.0-r256945 (snapshot)
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Dimitry Andric
URL:
Keywords:
Depends on: 206332 206333 206337 206527 206542 206545 206620 206650 207134 207192 207193 207196
Blocks: 212343
  Show dependency treegraph
 
Reported: 2016-01-09 14:54 UTC by Dimitry Andric
Modified: 2017-01-18 12:31 UTC (History)
4 users (show)

See Also:
dim: exp-run?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitry Andric freebsd_committer 2016-01-09 14:54:33 UTC
Quite soon, llvm, clang and lldb 3.8.0 will be branched off for release.  At the moment, we have imported 3.8.0-r256945 into the projects/clang380-import branch.

I would like to request an exp-run using this branch, to find regressions before the actual snapshot gets merged into head.  For testing, please use the projects/clang380-import branch here:

svn://svn.freebsd.org/base/projects/clang380-import

The branch has been updated to head r293429.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2016-01-10 18:46:32 UTC
Switch back to See Also, these issues are non-blocking. Apologies for the spam.
Comment 2 commit-hook freebsd_committer 2016-01-14 18:55:12 UTC
A commit references this bug:

Author: antoine
Date: Thu Jan 14 18:54:30 UTC 2016
New revision: 406126
URL: https://svnweb.freebsd.org/changeset/ports/406126

Log:
  Extend r405599 to make COMPILER_VERSION and ALT_COMPILER_VERSION more
  compatible with clang 3.8 trunk

  PR:		206074
  With hat:	portmgr

Changes:
  head/Mk/Uses/compiler.mk
  head/Mk/Uses/objc.mk
Comment 3 Antoine Brodin freebsd_committer 2016-01-17 07:58:42 UTC
Exp-run results on amd64:

http://package18.nyi.freebsd.org/build.html?mastername=headamd64PR206074-default&build=2016-01-15_15h26m58s

New failures:

+ {"origin"=>"comms/linrad", "pkgname"=>"linrad-4.02_3", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"databases/sfcgal", "pkgname"=>"sfcgal-1.1.0", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"devel/dee", "pkgname"=>"dee-1.2.7_1", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"devel/godot", "pkgname"=>"godot-1.1", "phase"=>"build", "errortype"=>"clang-bug"}
+ {"origin"=>"emulators/mednafen", "pkgname"=>"mednafen-0.9.33.2_4,1", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"emulators/simh", "pkgname"=>"simh-3.9.0", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"emulators/wine", "pkgname"=>"wine-1.8,1", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"emulators/wine-devel", "pkgname"=>"wine-devel-1.9.1,1", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"emulators/wine-staging", "pkgname"=>"wine-staging-1.9.1,1", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"games/bloodfrontier", "pkgname"=>"bloodfrontier-b2_10", "phase"=>"build", "errortype"=>"clang-bug"}
+ {"origin"=>"games/libretro-cores", "pkgname"=>"libretro-cores-0.20151110", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"games/sauerbraten", "pkgname"=>"sauerbraten-20130203_3", "phase"=>"build", "errortype"=>"clang-bug"}
+ {"origin"=>"games/spring", "pkgname"=>"spring-98.0", "phase"=>"build", "errortype"=>"clang-bug"}
+ {"origin"=>"games/xskat", "pkgname"=>"xskat-4.0_2", "phase"=>"build/runaway", "errortype"=>"runaway_process"}
+ {"origin"=>"lang/ecl", "pkgname"=>"ecl-15.3.7_1", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"lang/rust-nightly", "pkgname"=>"rust-nightly-1.3.0.20150703", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"mail/thunderbird", "pkgname"=>"thunderbird-38.5.0", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"www/firefox-esr", "pkgname"=>"firefox-esr-38.5.2,1", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"www/libxul", "pkgname"=>"libxul-38.5.2", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"www/seamonkey", "pkgname"=>"seamonkey-2.39_3", "phase"=>"build", "errortype"=>"clang-bug"}
+ {"origin"=>"x11-servers/x11rdp", "pkgname"=>"x11rdp-0.5.0.299_1", "phase"=>"build", "errortype"=>"configure_error"}
+ {"origin"=>"x11/leechcraft", "pkgname"=>"leechcraft-0.6.70_7", "phase"=>"build", "errortype"=>"???"}

Failure logs:

http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/linrad-4.02_3.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/sfcgal-1.1.0.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/dee-1.2.7_1.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/godot-1.1.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/mednafen-0.9.33.2_4,1.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/simh-3.9.0.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/wine-1.8,1.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/wine-devel-1.9.1,1.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/wine-staging-1.9.1,1.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/bloodfrontier-b2_10.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/libretro-cores-0.20151110.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/sauerbraten-20130203_3.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/spring-98.0.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/xskat-4.0_2.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/ecl-15.3.7_1.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/rust-nightly-1.3.0.20150703.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/thunderbird-38.5.0.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/firefox-esr-38.5.2,1.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/libxul-38.5.2.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/seamonkey-2.39_3.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/x11rdp-0.5.0.299_1.log
http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-15_15h26m58s/logs/errors/leechcraft-0.6.70_7.log
Comment 4 Antoine Brodin freebsd_committer 2016-01-17 08:03:46 UTC
On amd64, around 40 new ports were skipped mainly due to devel/dee and www/libxul.
Also lang/v8 is still broken with clang 3.7 and clang 3.8
Comment 5 Dimitry Andric freebsd_committer 2016-01-17 12:40:16 UTC
(In reply to Antoine Brodin from comment #4)
> On amd64, around 40 new ports were skipped mainly due to devel/dee and
> www/libxul.
> Also lang/v8 is still broken with clang 3.7 and clang 3.8

Hm, bug 202534 was to have fixed lang/v8 with clang 3.7, and the fix was committed by sunpoet in r397413.  So this got broken again in the mean time by some update, but nobody noticed? :-)
Comment 6 Dimitry Andric freebsd_committer 2016-01-17 12:53:13 UTC
Hm, lang/v8 builds just fine here.  Is there some sort of runtime error that I can check?
Comment 7 Dimitry Andric freebsd_committer 2016-01-17 13:24:09 UTC
(In reply to Dimitry Andric from comment #6)
> Hm, lang/v8 builds just fine here.  Is there some sort of runtime error that
> I can check?

Ah nevermind, it fails on amd64, similar to how it did on i386.  This looks easy to fix.
Comment 8 Dimitry Andric freebsd_committer 2016-01-17 14:03:44 UTC
Submitted bug 206332 for lang/v8 and lang/v8-devel.
Comment 9 Dimitry Andric freebsd_committer 2016-01-17 14:22:17 UTC
Submitted bug 206333 for www/libxul.
Comment 10 Dimitry Andric freebsd_committer 2016-01-17 14:56:25 UTC
Submitted bug 206337 for devel/dee.
Comment 11 Dimitry Andric freebsd_committer 2016-01-17 17:26:23 UTC
It looks like the comms/linrad assertion failure was fixed by an upstream commit in the mean time: it does not occur with clang version 3.8.0 (branches/release_38 257836) which I imported recently into the branch.  I'm attempting to pinpoint where it was fixed, precisely.
Comment 12 Dimitry Andric freebsd_committer 2016-01-17 23:44:56 UTC
(In reply to Dimitry Andric from comment #11)
> It looks like the comms/linrad assertion failure was fixed by an upstream
> commit in the mean time: it does not occur with clang version 3.8.0
> (branches/release_38 257836) which I imported recently into the branch.  I'm
> attempting to pinpoint where it was fixed, precisely.

It was fixed by this commit:
http://llvm.org/viewvc/llvm-project?view=revision&revision=257133
Comment 13 Dimitry Andric freebsd_committer 2016-01-18 07:48:35 UTC
I cannot seem to reproduce the devel/godot failure, neither with the earlier clang r256945 snapshot, nor with the more recent r257836 snapshot.  Is it possible to retrieve the /tmp/particle_system_sw-d3c7d1.{cpp,sh} files from one of the build slaves?
Comment 14 Antoine Brodin freebsd_committer 2016-01-18 17:51:50 UTC
Exp-run results on i386:

http://package18.nyi.freebsd.org/build.html?mastername=headi386PR206074-default&build=2016-01-17_07h20m29s

21 new failures, and around 220 new ports skipped (mainly due to editors/libreoffice, audio/lame and devel/dee) :

+ {"origin"=>"audio/lame", "pkgname"=>"lame-3.99.5_2", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"cad/gmsh", "pkgname"=>"gmsh-2.9.3", "phase"=>"build", "errortype"=>"clang-bug"}
+ {"origin"=>"cad/gmsh-occ", "pkgname"=>"gmsh-occ-2.9.3", "phase"=>"build", "errortype"=>"clang-bug"}
+ {"origin"=>"comms/usrp", "pkgname"=>"usrp-3.4.3_4", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"devel/dee", "pkgname"=>"dee-1.2.7_1", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"editors/libreoffice", "pkgname"=>"libreoffice-5.0.4", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"editors/neovim", "pkgname"=>"neovim-0.0.0.201507060407_1", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"emulators/mednafen", "pkgname"=>"mednafen-0.9.33.2_4,1", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"emulators/simh", "pkgname"=>"simh-3.9.0", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"games/libretro-cores", "pkgname"=>"libretro-cores-0.20151110", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"games/openastromenace", "pkgname"=>"openastromenace-1.3.2_3", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"games/xskat", "pkgname"=>"xskat-4.0_2", "phase"=>"build/runaway", "errortype"=>"runaway_process"}
+ {"origin"=>"lang/erlang-riak", "pkgname"=>"erlang-riak-16.b.02", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"mail/thunderbird", "pkgname"=>"thunderbird-38.5.0", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"math/cgal", "pkgname"=>"cgal-4.6", "phase"=>"build", "errortype"=>"clang-bug"}
+ {"origin"=>"security/pecl-scrypt", "pkgname"=>"pecl-scrypt-1.2_2", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"www/firefox-esr", "pkgname"=>"firefox-esr-38.5.2,1", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"www/libxul", "pkgname"=>"libxul-38.5.2", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"www/seamonkey", "pkgname"=>"seamonkey-2.39_3", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"x11-servers/x11rdp", "pkgname"=>"x11rdp-0.5.0.299_1", "phase"=>"build", "errortype"=>"configure_error"}
+ {"origin"=>"x11/leechcraft", "pkgname"=>"leechcraft-0.6.70_7", "phase"=>"build", "errortype"=>"???"}


Failure logs:

http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/lame-3.99.5_2.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/gmsh-2.9.3.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/gmsh-occ-2.9.3.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/usrp-3.4.3_4.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/dee-1.2.7_1.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/libreoffice-5.0.4.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/neovim-0.0.0.201507060407_1.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/mednafen-0.9.33.2_4,1.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/simh-3.9.0.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/libretro-cores-0.20151110.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/openastromenace-1.3.2_3.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/xskat-4.0_2.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/erlang-riak-16.b.02.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/thunderbird-38.5.0.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/cgal-4.6.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/pecl-scrypt-1.2_2.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/firefox-esr-38.5.2,1.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/libxul-38.5.2.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/seamonkey-2.39_3.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/x11rdp-0.5.0.299_1.log
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/leechcraft-0.6.70_7.log
Comment 16 Dimitry Andric freebsd_committer 2016-01-18 18:35:07 UTC
(In reply to Antoine Brodin from comment #15)
> For devel/godot:
> 
> http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-
> 18_17h54m59s/logs/particle_system_sw-21810a.cpp
> http://package18.nyi.freebsd.org/data/headamd64PR206074-default/2016-01-
> 18_17h54m59s/logs/particle_system_sw-21810a.sh

Thanks, I was able to reproduce them anyway, after some experimentation. These are also fixed by upstream llvm commit r257133, similar to the comms/linrad failure.  E.g. both failures should be fixed after the import of the latest 3.8 branch into the clang380-import branch, which is now at (base commit) r294179.
Comment 17 Dimitry Andric freebsd_committer 2016-01-18 18:54:35 UTC
Submitted bug 206376 for emulators/mednafen.
Comment 18 Dimitry Andric freebsd_committer 2016-01-19 20:17:12 UTC
Submitted bug 206411 for emulators/simh.
Comment 19 Dimitry Andric freebsd_committer 2016-01-19 20:37:15 UTC
I can confirm that databases/sfcgal's failure is fixed by upstream r258110 (see also http://llvm.org/PR26134 ), which I imported in (our) r294337.

Btw, why is sfcgal under databases?  It looks much more like a mathematics library, full of tricky 2D and 3D transformations... :)
Comment 20 Dimitry Andric freebsd_committer 2016-01-19 22:53:33 UTC
Strangely, I cannot reproduce the emulators/wine failure. It compiles fine for me on i386, but on amd64 it fails much earlier, when the dependency graphics/lcms2 is built, with:

===>   wine-1.8,1 depends on shared library: liblcms2.so - not found
===>  Building for lcms2-2.7_2
--- all-recursive ---
Making all in src
Making all in include
Making all in utils/tificc
Making all in utils/transicc
--- transicc ---
/bin/sh ../../libtool --tag=CC    --mode=link cc  -O2 -pipe -march=ivybridge  -isystem /usr/local/include -fstack-protector -fno-strict-aliasing -D_THREAD_SAFE -pthread -L/usr/local/lib -fstack-protector  -L/usr/local/lib -fstack-protector -o transicc transicc.o xgetopt.o  vprf.o ../../src/liblcms2.la
libtool: link: cc -O2 -pipe -march=ivybridge -isystem /usr/local/include -fstack-protector -fno-strict-aliasing -D_THREAD_SAFE -pthread -fstack-protector -fstack-protector -o .libs/transicc transicc.o xgetopt.o vprf.o  -L/usr/local/lib ../../src/.libs/liblcms2.so -lpthread -pthread -Wl,-rpath -Wl,/usr/local/lib
../../src/.libs/liblcms2.so: undefined reference to `log'
../../src/.libs/liblcms2.so: undefined reference to `atan'
../../src/.libs/liblcms2.so: undefined reference to `exp'
../../src/.libs/liblcms2.so: undefined reference to `sin'
../../src/.libs/liblcms2.so: undefined reference to `pow'
../../src/.libs/liblcms2.so: undefined reference to `atan2'
../../src/.libs/liblcms2.so: undefined reference to `cos'
../../src/.libs/liblcms2.so: undefined reference to `log10'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [transicc] Error code 1

Sunpoet, you're also lcms2 maintainer, any idea what is going on?  I assume lcms2 normally builds, but the above appears to be caused by it not adding -lm to the link command line.
Comment 21 Dimitry Andric freebsd_committer 2016-01-23 15:53:31 UTC
(In reply to Dimitry Andric from comment #20)
> Strangely, I cannot reproduce the emulators/wine failure. It compiles fine
> for me on i386, but on amd64 it fails much earlier, when the dependency
> graphics/lcms2 is built, with:
...> libtool: link: cc -O2 -pipe -march=ivybridge -isystem /usr/local/include
> -fstack-protector -fno-strict-aliasing -D_THREAD_SAFE -pthread
> -fstack-protector -fstack-protector -o .libs/transicc transicc.o xgetopt.o
> vprf.o  -L/usr/local/lib ../../src/.libs/liblcms2.so -lpthread -pthread
> -Wl,-rpath -Wl,/usr/local/lib
> ../../src/.libs/liblcms2.so: undefined reference to `log'
> ../../src/.libs/liblcms2.so: undefined reference to `atan'
> ../../src/.libs/liblcms2.so: undefined reference to `exp'
> ../../src/.libs/liblcms2.so: undefined reference to `sin'
> ../../src/.libs/liblcms2.so: undefined reference to `pow'
> ../../src/.libs/liblcms2.so: undefined reference to `atan2'
> ../../src/.libs/liblcms2.so: undefined reference to `cos'
> ../../src/.libs/liblcms2.so: undefined reference to `log10'

This turned out to be an assertion failure when certain math functions (e.g. sqrt()) were redefined [1], so the configure script for lcms2 never detected that -lm had to be used.  The fix for this assertion failure was merged with a recent update to llvm/clang r258549 in the clang380-import branch [2].

[1] https://llvm.org/bugs/show_bug.cgi?id=26211
[2] https://svnweb.freebsd.org/base?view=revision&revision=294609
Comment 22 Dimitry Andric freebsd_committer 2016-01-23 15:54:11 UTC
Submitted bug 206527 for emulators/wine and emulators/wine-devel.
Comment 23 Dimitry Andric freebsd_committer 2016-01-23 19:34:08 UTC
The following list of ports were all fixed by upstream llvm commit r257133, which went into the clang380-import branch recently:
* comms/linrad
* devel/godot
* games/bloodfrontier
* games/sauerbraten
* games/spring
Comment 24 Dimitry Andric freebsd_committer 2016-01-23 22:13:31 UTC
Submitted bug 206542 for games/libretro-cores.
Comment 25 Dimitry Andric freebsd_committer 2016-01-23 22:19:47 UTC
I could reproduce the games/skat hang (on skat.c) with clang 3.8.0 r256945, but the more recent version now merged into the clang380-import branch (r258549) appears to have solved it.  It compiles pretty quickly now, even. :)
Comment 26 Dimitry Andric freebsd_committer 2016-01-23 22:52:40 UTC
Submitted bug 206545 for mail/thunderbird.
Comment 27 Dimitry Andric freebsd_committer 2016-01-24 16:29:37 UTC
I could reproduce the segfaults that lang/ecl got on amd64 during its build, with clang 3.8.0 r256945, but the more recent version now merged into the clang380-import branch (r258549) appears to have solved it.
Comment 28 Dimitry Andric freebsd_committer 2016-01-24 22:47:18 UTC
I cannot reproduce the x11-servers/x11rdp error.  In the exp-run, it terminated with a pretty strange error:

    checking for SM... configure: error: Package requirements (ice xproto) were not met:

    Package ice was not found in the pkg-config search path.
    Perhaps you should add the directory containing `ice.pc'
    to the PKG_CONFIG_PATH environment variable
    Package 'ice', required by 'world', not found

E.g. it seems as if the build dependencies were not installed correctly?

In my case, however, it configures fine and starts building, but eventually gets a compilation error:

In file included from icetrans.c:33:
In file included from /usr/work/share/dim/ports/x11-servers/x11rdp/work/x11rdp_xorg71/build_dir/include/X11/Xtrans/transport.c:80:
/usr/work/share/dim/ports/x11-servers/x11rdp/work/x11rdp_xorg71/build_dir/include/X11/Xtrans/Xtranssock.c:1027:50: error: reference to 'in6addr_any'
      is ambiguous
        ((struct sockaddr_in6 *)&sockname)->sin6_addr = in6addr_any;
                                                        ^
/usr/work/share/dim/ports/x11-servers/x11rdp/work/x11rdp_xorg71/build_dir/include/X11/Xtrans/Xtranssock.c:289:30: note: candidate found by name
      lookup is 'in6addr_any'
static const struct in6_addr local_in6addr_any = IN6ADDR_ANY_INIT;
                             ^
/usr/include/netinet6/in6.h:209:30: note: candidate found by name lookup is 'in6addr_any'
extern const struct in6_addr in6addr_any;
                             ^

It looks like this is caused by a duplicate definition of in6addr_any.
Comment 29 Dimitry Andric freebsd_committer 2016-01-25 19:39:43 UTC
Submitted bug 206620 for audio/lame.
Comment 30 Dimitry Andric freebsd_committer 2016-01-26 18:57:32 UTC
Submitted bug 206650 for x11/leechcraft.
Comment 31 Dimitry Andric freebsd_committer 2016-01-27 17:34:00 UTC
I cannot reproduce the lang/rust-nightly failure.  For me, with both clang 3.7.1 (as it is now in head) and 3.8.0, the build of the rust compiler itself goes fine, but when it is compiling its standard libraries, it hangs, e.g.:

[...]
rustc: x86_64-unknown-freebsd/stage0/lib/rustlib/x86_64-unknown-freebsd/lib/liblibc
rustc: x86_64-unknown-freebsd/stage0/lib/rustlib/x86_64-unknown-freebsd/lib/librand
rustc: x86_64-unknown-freebsd/stage0/lib/rustlib/x86_64-unknown-freebsd/lib/librustc_unicode
rustc: x86_64-unknown-freebsd/stage0/lib/rustlib/x86_64-unknown-freebsd/lib/librustc_bitflags
rustc: x86_64-unknown-freebsd/stage0/lib/rustlib/x86_64-unknown-freebsd/lib/liballoc
rustc: x86_64-unknown-freebsd/stage0/lib/rustlib/x86_64-unknown-freebsd/lib/libcollections
rustc: x86_64-unknown-freebsd/stage0/lib/rustlib/x86_64-unknown-freebsd/lib/libstd

From this point, rustc is spinning with max CPU.  I let it run for an hour or so, then I killed the build.  I suspect there is some sort of bug or undefined behavior in rustc nightly, causing it to fall into a busy loop.
Comment 32 Antoine Brodin freebsd_committer 2016-01-27 20:07:53 UTC
(In reply to Dimitry Andric from comment #31)
There is a bug in rtld in head causing this spin (see https://lists.freebsd.org/pipermail/svn-src-head/2016-January/081880.html )
Comment 33 Dimitry Andric freebsd_committer 2016-01-27 22:43:06 UTC
The cad/gmsh failure is exactly the same problem as we encountered some time ago in inkscape.  This was reported upstream in December 2014 as https://llvm.org/bugs/show_bug.cgi?id=21903, but still no resolution. :-(
Comment 34 Dimitry Andric freebsd_committer 2016-02-12 18:15:47 UTC
Submitted bug 207134 for graphics/libfpx.
Comment 35 Antoine Brodin freebsd_committer 2016-02-14 11:01:15 UTC
Exp-run results on i386 with libfpx fix applied:

http://package23.nyi.freebsd.org/build.html?mastername=headi386PR206074-default&build=2016-02-14_06h51m58s

New failures:

+ {"origin"=>"cad/gmsh", "pkgname"=>"gmsh-2.11.0", "phase"=>"build", "errortype"=>"clang-bug"}
+ {"origin"=>"cad/gmsh-occ", "pkgname"=>"gmsh-occ-2.11.0", "phase"=>"build", "errortype"=>"clang-bug"}
+ {"origin"=>"comms/usrp", "pkgname"=>"usrp-3.4.3_4", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"emulators/mednafen", "pkgname"=>"mednafen-0.9.33.2_4,1", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"games/openastromenace", "pkgname"=>"openastromenace-1.3.2_3", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"math/cgal", "pkgname"=>"cgal-4.6_1", "phase"=>"build", "errortype"=>"clang-bug"}
+ {"origin"=>"palm/palm-db-tools", "pkgname"=>"palm-db-tools-0.3.6", "phase"=>"build", "errortype"=>"makefile"}
+ {"origin"=>"security/pecl-scrypt", "pkgname"=>"pecl-scrypt-1.2_2", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"sysutils/fusefs-chironfs", "pkgname"=>"fusefs-chironfs-1.1.1_1", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"www/uwsgi", "pkgname"=>"uwsgi-2.0.12_1", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"x11-servers/x11rdp", "pkgname"=>"x11rdp-0.5.0.299_1", "phase"=>"build", "errortype"=>"configure_error"}

Failure logs:

http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/gmsh-2.11.0.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/gmsh-occ-2.11.0.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/usrp-3.4.3_4.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/mednafen-0.9.33.2_4,1.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/openastromenace-1.3.2_3.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/cgal-4.6_1.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/palm-db-tools-0.3.6.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/pecl-scrypt-1.2_2.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/fusefs-chironfs-1.1.1_1.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/uwsgi-2.0.12_1.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/x11rdp-0.5.0.299_1.log
Comment 36 Antoine Brodin freebsd_committer 2016-02-14 12:00:58 UTC
Exp-run results on amd64 with libfpx fix applied:

http://package22.nyi.freebsd.org/build.html?mastername=headamd64PR206074-default&build=2016-02-14_06h53m40s

New failures:

+ {"origin"=>"emulators/mednafen", "pkgname"=>"mednafen-0.9.33.2_4,1", "phase"=>"build", "errortype"=>"???"}
+ {"origin"=>"lang/rust-nightly", "pkgname"=>"rust-nightly-1.3.0.20150703", "phase"=>"build", "errortype"=>"linker_error"}
+ {"origin"=>"palm/palm-db-tools", "pkgname"=>"palm-db-tools-0.3.6", "phase"=>"build", "errortype"=>"makefile"}
+ {"origin"=>"sysutils/fusefs-chironfs", "pkgname"=>"fusefs-chironfs-1.1.1_1", "phase"=>"build", "errortype"=>"coredump"}
+ {"origin"=>"www/uwsgi", "pkgname"=>"uwsgi-2.0.12_1", "phase"=>"build", "errortype"=>"clang_werror"}
+ {"origin"=>"x11-servers/x11rdp", "pkgname"=>"x11rdp-0.5.0.299_1", "phase"=>"build", "errortype"=>"configure_error"}

Failure logs:

http://package22.nyi.freebsd.org/data/headamd64PR206074-default/2016-02-14_06h53m40s/logs/errors/mednafen-0.9.33.2_4,1.log
http://package22.nyi.freebsd.org/data/headamd64PR206074-default/2016-02-14_06h53m40s/logs/errors/rust-nightly-1.3.0.20150703.log
http://package22.nyi.freebsd.org/data/headamd64PR206074-default/2016-02-14_06h53m40s/logs/errors/palm-db-tools-0.3.6.log
http://package22.nyi.freebsd.org/data/headamd64PR206074-default/2016-02-14_06h53m40s/logs/errors/fusefs-chironfs-1.1.1_1.log
http://package22.nyi.freebsd.org/data/headamd64PR206074-default/2016-02-14_06h53m40s/logs/errors/uwsgi-2.0.12_1.log
http://package22.nyi.freebsd.org/data/headamd64PR206074-default/2016-02-14_06h53m40s/logs/errors/x11rdp-0.5.0.299_1.log

Corrected failure logs on i386:

http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/logs/errors/gmsh-2.11.0.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/logs/errors/gmsh-occ-2.11.0.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/logs/errors/usrp-3.4.3_4.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/logs/errors/mednafen-0.9.33.2_4,1.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/logs/errors/openastromenace-1.3.2_3.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/logs/errors/cgal-4.6_1.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/logs/errors/palm-db-tools-0.3.6.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/logs/errors/pecl-scrypt-1.2_2.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/logs/errors/fusefs-chironfs-1.1.1_1.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/logs/errors/uwsgi-2.0.12_1.log
http://package23.nyi.freebsd.org/data/headi386PR206074-default/2016-02-14_06h51m58s/logs/errors/x11rdp-0.5.0.299_1.log
Comment 37 Dimitry Andric freebsd_committer 2016-02-14 21:24:53 UTC
Submitted bug 207192 for x11-servers/x11rdp.
Comment 38 Dimitry Andric freebsd_committer 2016-02-14 21:34:12 UTC
Submitted bug 207193 for palm/palm-db-tools.
Comment 39 Dimitry Andric freebsd_committer 2016-02-14 21:41:39 UTC
The sysutils/fusefs-chironfs assertion failure ('Offset <= PieceOffset && "overlapping or duplicate pieces"') was LLVM upstream PR26148 [1].  This bug was fixed in LLVM upstream commit r259696 [2], which was merged to the 3.8 branch in r260121 [3].

Unfortunately I only imported that fix on Feb 13 [4], so it was slightly too late for the exp-run.  I built the port just now, and I see no assertions anymore.

[1] https://llvm.org/bugs/show_bug.cgi?id=26148
[2] http://llvm.org/viewvc/llvm-project?view=revision&revision=259696
[3] http://llvm.org/viewvc/llvm-project?view=revision&revision=260121
[4] https://svnweb.freebsd.org/changeset/base/295600
Comment 40 Dimitry Andric freebsd_committer 2016-02-14 22:03:34 UTC
Submitted bug 207196 for www/uwsgi.
Comment 41 Mikhail Teterin freebsd_committer 2016-02-19 03:22:45 UTC
The lang/clang38 has OpenMP support, but, when I try to build graphics/ImageMagick with OpenMP enabled, gcc49 is picked as the compiler -- instead of clang38. Can this, perhaps, be reversed? gcc49's insistence on using its own libgcc.so makes it undesireable...
Comment 42 Dimitry Andric freebsd_committer 2016-02-23 21:44:15 UTC
(In reply to Mikhail Teterin from comment #41)
> The lang/clang38 has OpenMP support, but, when I try to build
> graphics/ImageMagick with OpenMP enabled, gcc49 is picked as the compiler --
> instead of clang38. Can this, perhaps, be reversed? gcc49's insistence on
> using its own libgcc.so makes it undesireable...

Please report this as a separate bug for the lang/clang38 port, so Brooks can take a look at it.  This bug is about the version of clang in base, which will not have OpenMP support (at least not out of the box).
Comment 43 Dimitry Andric freebsd_committer 2016-03-20 14:19:26 UTC
Closing since 3.8.0 was merged to head recently.