Re: update: devel/llvm

2015-11-22 Thread Jonathan Gray 
On Thu, Nov 12, 2015 at 10:25:53AM +0100, Pascal Stumpf wrote:
> On Thu, 12 Nov 2015 00:08:35 +0100, Christian Weisgerber wrote:
> > Pascal Stumpf:
> > 
> > > I have done manual builds of some ports that use clang (various
> > > firefoxes, multimedia stuff, vlc, mplayer), but maybe this needs a bulk
> > > build?
> > 
> > If I get a complete patch, I can kick off an amd64 bulk build with it
> > tom^Hday.
> 
> Next try to get the diff unmangled.  If that fails, it's on cvs too ...

I tried to build mesa git with clang/clang++ but it seems clang can't
compile it's own headers?

libtool: compile:  /usr/local/bin/clang++ -DPACKAGE_NAME=\"Mesa\" 
-DPACKAGE_TARNAME=\"mesa\" -DPACKAGE_VERSION=\"11.2.0-devel\" 
"-DPACKAGE_STRING=\"Mesa 11.2.0-devel\"" 
"-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\";
 -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"11.2.0-devel\" 
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
-DYYTEXT_POINTER=1 -DHAVE___BUILTIN_BSWAP32=1 -DHAVE___BUILTIN_BSWAP64=1 
-DHAVE___BUILTIN_CLZ=1 -DHAVE___BUILTIN_CLZLL=1 -DHAVE___BUILTIN_CTZ=1 
-DHAVE___BUILTIN_EXPECT=1 -DHAVE___BUILTIN_FFS=1 -DHAVE___BUILTIN_FFSLL=1 
-DHAVE___BUILTIN_POPCOUNT=1 -DHAVE___BUILTIN_POPCOUNTLL=1 
-DHAVE___BUILTIN_UNREACHABLE=1 -DHAVE_FUNC_ATTRIBUTE_CONST=1 
-DHAVE_FUNC_ATTRIBUTE_FLATTEN=1 -DHAVE_FUNC_ATTRIBUTE_FORMAT=1 
-DHAVE_FUNC_ATTRIBUTE_MALLOC=1 -DHAVE_FUNC_ATTRIBUTE_PACKED=1 
-DHAVE_FUNC_ATTRIBUTE_PURE=1 -DHAVE_FUNC_ATTRIBUTE_UNUSED=1 
-DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT=1 -DHAVE_DLADDR=1 
-DHAVE_CLOCK_GETTIME=1 -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 
-DHAVE_SHA1_IN_LIBC=1 -I. -fvisibility=hidden -Werror=pointer-arith -Werror=vla 
-I../../../include -I../../../src -I../../../src/gallium/include 
-I../../../src/gallium/auxiliary -D__STDC_LIMIT_MACROS -DUSE_SSE41 -DDEBUG 
-DUSE_X86_64_ASM -DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF -DHAVE_MKOSTEMP 
-DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DHAVE_SHA1 -DGLX_USE_DRM 
-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DHAVE_MINCORE 
-DHAVE_LLVM=0x0307 -DMESA_LLVM_VERSION_PATCH=0 -I/usr/local/include -pipe -W 
-Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers 
-Wno-long-long -Wno-maybe-uninitialized -Wno-comment -std=c++11 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -g -O2 
-Wall -fno-strict-aliasing -fno-builtin-memcmp -Qunused-arguments -MT 
gallivm/lp_bld_debug.lo -MD -MP -MF gallivm/.deps/lp_bld_debug.Tpo -c 
gallivm/lp_bld_debug.cpp  -fPIC -DPIC -o gallivm/.libs/lp_bld_debug.o
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean 
'-Wno-uninitialized'? [-Wunknown-warning-option]
In file included from gallivm/lp_bld_debug.cpp:32:
In file included from /usr/local/include/llvm/Support/raw_ostream.h:17:
In file included from /usr/local/include/llvm/ADT/SmallVector.h:17:
/usr/local/include/llvm/ADT/iterator_range.h:36:29: error: no member named 
'move' in namespace 'std'; did you mean 'modf'?
  : begin_iterator(std::move(begin_iterator)),
   ~^~~~
modf
/usr/include/math.h:200:8: note: 'modf' declared here
double modf(double, double *);
   ^
In file included from gallivm/lp_bld_debug.cpp:32:
In file included from /usr/local/include/llvm/Support/raw_ostream.h:17:
In file included from /usr/local/include/llvm/ADT/SmallVector.h:17:
/usr/local/include/llvm/ADT/iterator_range.h:37:27: error: no member named 
'move' in namespace 'std'; did you mean 'modf'?
end_iterator(std::move(end_iterator)) {}
 ~^~~~
  modf
/usr/include/math.h:200:8: note: 'modf' declared here
double modf(double, double *);
   ^
In file included from gallivm/lp_bld_debug.cpp:32:
In file included from /usr/local/include/llvm/Support/raw_ostream.h:17:
In file included from /usr/local/include/llvm/ADT/SmallVector.h:17:
/usr/local/include/llvm/ADT/iterator_range.h:48:33: error: no member named 
'move' in namespace 'std'; did you mean 'modf'?
  return iterator_range(std::move(x), std::move(y));
   ~^~~~
modf
/usr/include/math.h:200:8: note: 'modf' declared here
double modf(double, double *);
   ^
In file included from gallivm/lp_bld_debug.cpp:32:
In file included from /usr/local/include/llvm/Support/raw_ostream.h:17:
In file included from /usr/local/include/llvm/ADT/SmallVector.h:17:
/usr/local/include/llvm/ADT/iterator_range.h:48:47: error: no member named 
'move' in namespace 'std'; did you mean 'modf'?
  return iterator_range(std::move(x), std::move(y));
 ~^~~~
  modf
/usr/include/math.h:200:8: note: 'modf' declared here
double modf(double, double

Re: update: devel/llvm

2015-11-13 Thread Stuart Henderson 
On 2015/11/12 20:53, Stuart Henderson wrote:
> Here's the first i386 failure, in devel/xulrunner/24:

That was the only build-time fallout. It's not so easy for to actually
run those packages though.

Re: update: devel/llvm

2015-11-13 Thread Christian Weisgerber 
On 2015-11-12, Stuart Henderson  wrote:

> Here's the first i386 failure, in devel/xulrunner/24:

amd64, tail -100:

INPUT("../../gfx/skia/SkImage_Raster.o")
INPUT("../../gfx/skia/SkLayerDrawLooper.o")
INPUT("../../gfx/skia/SkLayerRasterizer.o")
INPUT("../../gfx/skia/SkLineClipper.o")
INPUT("../../gfx/skia/SkLinearGradient.o")
INPUT("../../gfx/skia/SkMallocPixelRef.o")
INPUT("../../gfx/skia/SkMask.o")
INPUT("../../gfx/skia/SkMaskFilter.o")
INPUT("../../gfx/skia/SkMaskGamma.o")
INPUT("../../gfx/skia/SkMath.o")
INPUT("../../gfx/skia/SkMatrix.o")
INPUT("../../gfx/skia/SkMemory_malloc.o")
INPUT("../../gfx/skia/SkMetaData.o")
INPUT("../../gfx/skia/SkOSFile_stdio.o")
INPUT("../../gfx/skia/SkOTUtils.o")
INPUT("../../gfx/skia/SkOrderedReadBuffer.o")
INPUT("../../gfx/skia/SkOrderedWriteBuffer.o")
INPUT("../../gfx/skia/SkPackBits.o")
INPUT("../../gfx/skia/SkPaint.o")
INPUT("../../gfx/skia/SkPath.o")
INPUT("../../gfx/skia/SkPathEffect.o")
INPUT("../../gfx/skia/SkPathHeap.o")
INPUT("../../gfx/skia/SkPathMeasure.o")
INPUT("../../gfx/skia/SkPicture.o")
INPUT("../../gfx/skia/SkPictureFlat.o")
INPUT("../../gfx/skia/SkPicturePlayback.o")
INPUT("../../gfx/skia/SkPictureRecord.o")
INPUT("../../gfx/skia/SkPictureStateTree.o")
INPUT("../../gfx/skia/SkPixelRef.o")
INPUT("../../gfx/skia/SkPoint.o")
INPUT("../../gfx/skia/SkProcSpriteBlitter.o")
INPUT("../../gfx/skia/SkPtrRecorder.o")
INPUT("../../gfx/skia/SkQuadClipper.o")
INPUT("../../gfx/skia/SkRTree.o")
INPUT("../../gfx/skia/SkRadialGradient.o")
INPUT("../../gfx/skia/SkRasterClip.o")
INPUT("../../gfx/skia/SkRasterizer.o")
INPUT("../../gfx/skia/SkRect.o")
INPUT("../../gfx/skia/SkRefDict.o")
INPUT("../../gfx/skia/SkRegion.o")
INPUT("../../gfx/skia/SkRegion_path.o")
INPUT("../../gfx/skia/SkRegion_rects.o")
INPUT("../../gfx/skia/SkScalar.o")
INPUT("../../gfx/skia/SkScalerContext.o")
INPUT("../../gfx/skia/SkScan.o")
INPUT("../../gfx/skia/SkScan_AntiPath.o")
INPUT("../../gfx/skia/SkScan_Antihair.o")
INPUT("../../gfx/skia/SkScan_Hairline.o")
INPUT("../../gfx/skia/SkScan_Path.o")
INPUT("../../gfx/skia/SkShader.o")
INPUT("../../gfx/skia/SkSpriteBlitter_ARGB32.o")
INPUT("../../gfx/skia/SkSpriteBlitter_RGB16.o")
INPUT("../../gfx/skia/SkStream.o")
INPUT("../../gfx/skia/SkString.o")
INPUT("../../gfx/skia/SkStroke.o")
INPUT("../../gfx/skia/SkStrokerPriv.o")
INPUT("../../gfx/skia/SkSurface.o")
INPUT("../../gfx/skia/SkSurface_Picture.o")
INPUT("../../gfx/skia/SkSurface_Raster.o")
INPUT("../../gfx/skia/SkSweepGradient.o")
INPUT("../../gfx/skia/SkTLS.o")
INPUT("../../gfx/skia/SkTSearch.o")
INPUT("../../gfx/skia/SkTwoPointConicalGradient.o")
INPUT("../../gfx/skia/SkTwoPointRadialGradient.o")
INPUT("../../gfx/skia/SkTypeface.o")
INPUT("../../gfx/skia/SkTypefaceCache.o")
INPUT("../../gfx/skia/SkUnPreMultiply.o")
INPUT("../../gfx/skia/SkUtils.o")
INPUT("../../gfx/skia/SkWriter32.o")
INPUT("../../gfx/skia/SkXfermode.o")
INPUT("../../media/webvtt/alloc.o")
INPUT("../../media/webvtt/cue.o")
INPUT("../../media/webvtt/cuetext.o")
INPUT("../../media/webvtt/error.o")
INPUT("../../media/webvtt/lexer.o")
INPUT("../../media/webvtt/node.o")
INPUT("../../media/webvtt/parser.o")
INPUT("../../media/webvtt/string.o")

../../layout/svg/nsSVGFilterFrame.o: In function `tag_nsresult 
CallQueryInterface(nsIContent*, nsSVGFE**)':
../../dist/include/nsISupportsUtils.h:148: undefined reference to 
`nsSVGFE::COMTypeInfo::kIID'
/usr/bin/ld: ../../layout/svg/nsSVGFilterFrame.o: relocation R_X86_64_PC32 
against `_ZN7nsSVGFE11COMTypeInfoIiE4kIIDE' can not be used when making a 
shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
clang-3.7: error: linker command failed with exit code 1 (use -v to see 
invocation)
/usr/obj/ports/xulrunner-24.8.0/mozilla-esr24/config/rules.mk:1023: recipe for 
target 'libxul.so.0.0' failed
gmake[3]: *** [libxul.so.0.0] Error 1
gmake[3]: Leaving directory 
'/usr/obj/ports/xulrunner-24.8.0/build-amd64/toolkit/library'
/usr/obj/ports/xulrunner-24.8.0/mozilla-esr24/config/makefiles/target_libs.mk:16:
 recipe for target 'libs_tier_platform' failed
gmake[2]: *** [libs_tier_platform] Error 2
gmake[2]: Leaving directory '/usr/obj/ports/xulrunner-24.8.0/build-amd64'
/usr/obj/ports/xulrunner-24.8.0/mozilla-esr24/config/rules.mk:737: recipe for 
target 'tier_platform' failed
gmake[1]: *** [tier_platform] Error 2
gmake[1]: Leaving directory '/usr/obj/ports/xulrunner-24.8.0/build-amd64'
/usr/obj/ports/xulrunner-24.8.0/mozilla-esr24/config/rules.mk:670: recipe for 
target 'all' failed
gmake: *** [all] Error 2
*** Error 2 in devel/xulrunner/24 
(/usr/ports/infrastructure/mk/bsd.port.mk:2770

Re: update: devel/llvm

2015-11-13 Thread Christian Weisgerber 
On 2015-11-11, Christian Weisgerber  wrote:

> If I get a complete patch, I can kick off an amd64 bulk build with it
> tom^Hday.

The results are in: devel/xulrunner/24 suffers explosive diarrhea
and eventually dies.  No problems otherwise.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: update: devel/llvm

2015-11-12 Thread Stuart Henderson 
Here's the first i386 failure, in devel/xulrunner/24:

[...]
INPUT("../../media/webvtt/error.o")
INPUT("../../media/webvtt/lexer.o")
INPUT("../../media/webvtt/node.o")
INPUT("../../media/webvtt/parser.o")
INPUT("../../media/webvtt/string.o")

/usr/obj/ports/xulrunner-24.8.0/mozilla-esr24/config/rules.mk:1023: recipe for 
target 'libxul.so.0.0' failed
gmake[3]: Leaving directory 
'/usr/obj/ports/xulrunner-24.8.0/build-i386/toolkit/library'
/usr/obj/ports/xulrunner-24.8.0/mozilla-esr24/config/makefiles/target_libs.mk:16:
 recipe for target 'libs_tier_platform' failed
gmake[2]: Leaving directory '/usr/obj/ports/xulrunner-24.8.0/build-i386'
/usr/obj/ports/xulrunner-24.8.0/mozilla-esr24/config/rules.mk:737: recipe for 
target 'tier_platform' failed
gmake[1]: Leaving directory '/usr/obj/ports/xulrunner-24.8.0/build-i386'
/usr/obj/ports/xulrunner-24.8.0/mozilla-esr24/config/rules.mk:670: recipe for 
target 'all' failed
===> Exiting devel/xulrunner/24 with an error
../../layout/svg/nsSVGFilterFrame.o: In function 
`nsSVGFilterFrame::GetFilterContent(nsIContent*)':
/usr/obj/ports/xulrunner-24.8.0/mozilla-esr24/layout/svg/nsSVGFilterFrame.cpp:(.text._ZN16nsSVGFilterFrame16GetFilterContentEP10nsIContent+0x31):
 undefined reference to `nsSVGFE::COMTypeInfo::kIID'
../../layout/svg/nsSVGFilterInstance.o: In function 
`nsSVGFilterInstance::BuildPrimitives()':
/usr/obj/ports/xulrunner-24.8.0/mozilla-esr24/layout/svg/nsSVGFilterInstance.cpp:(.text._ZN19nsSVGFilterInstance15BuildPrimitivesEv+0x48):
 undefined reference to `nsSVGFE::COMTypeInfo::kIID'
../../content/svg/content/src/SVGFEComponentTransferElement.o: In function 
`mozilla::dom::SVGFEComponentTransferElement::Filter(nsSVGFilterInstance*, 
nsTArray const&, nsSVGFE::Image const*, nsIntRect 
const&)':
/usr/obj/ports/xulrunner-24.8.0/mozilla-esr24/content/svg/content/src/SVGFEComponentTransferElement.cpp:(.text._ZN7mozilla3dom29SVGFEComponentTransferElement6FilterEP19nsSVGFilterInstanceRK8nsTArrayIPKN7nsSVGFE5ImageEES8_RK9nsIntRect+0xbc):
 undefined reference to 
`mozilla::dom::SVGComponentTransferFunctionElement::COMTypeInfo::kIID'
/usr/bin/ld: libxul.so.0.0: hidden symbol `_ZN7nsSVGFE11COMTypeInfoIiE4kIIDE' 
isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
clang-3.7: error: linker command failed with exit code 1 (use -v to see 
invocation)

I won't include the whole log here as uncompressed it's just about big
enough to fill a CD...

Re: update: devel/llvm

2015-11-11 Thread Stuart Henderson 
On 2015/11/11 10:26, Michael McConville wrote:
> Pascal Stumpf wrote:
> > mmc@ reminded me that I had been slacking on getting this into the tree.
> > 
> > This patch updates LLVM to version 3.7, using GCC from ports as a
> > compiler, and using its headers and libstdc++ at runtime.  The downside
> > is, of course, that everything compiled with clang++ will now depend on
> > libstdc++ from ports.  But until we have libc++, there is really nothing
> > else we can do.  Having a modern LLVM with a complete C++11 featureset
> > is more important.
> > 
> > Works on amd64, i386 and sparc64.  powerpc and mips64 are still WIP,
> > both upstream and portwise.
> > 
> > The patch below is only the update itself.  This also needs patches to
> > gcc4.port.mk as well as clang.port.mk to integrate the new libstdc++
> > logic.  I will send these shortly.
> 
> I've been running this for weeks and have used it for some big builds.
> No apparent problems. ok mmcc@
> 

What testing has been done so far in the ports tree?

Re: update: devel/llvm

2015-11-11 Thread Michael McConville 
Stuart Henderson wrote:
> On 2015/11/11 10:26, Michael McConville wrote:
> > Pascal Stumpf wrote:
> > > mmc@ reminded me that I had been slacking on getting this into the tree.
> > > 
> > > This patch updates LLVM to version 3.7, using GCC from ports as a
> > > compiler, and using its headers and libstdc++ at runtime.  The downside
> > > is, of course, that everything compiled with clang++ will now depend on
> > > libstdc++ from ports.  But until we have libc++, there is really nothing
> > > else we can do.  Having a modern LLVM with a complete C++11 featureset
> > > is more important.
> > > 
> > > Works on amd64, i386 and sparc64.  powerpc and mips64 are still WIP,
> > > both upstream and portwise.
> > > 
> > > The patch below is only the update itself.  This also needs patches to
> > > gcc4.port.mk as well as clang.port.mk to integrate the new libstdc++
> > > logic.  I will send these shortly.
> > 
> > I've been running this for weeks and have used it for some big builds.
> > No apparent problems. ok mmcc@
> > 
> 
> What testing has been done so far in the ports tree?

IIRC, I built Landry's Firefox beta with it. I also use scan-build
often.

Re: update: devel/llvm

2015-11-11 Thread Pascal Stumpf 
On Wed, 11 Nov 2015 17:32:35 +, Stuart Henderson wrote:
> On 2015/11/11 10:26, Michael McConville wrote:
> > Pascal Stumpf wrote:
> > > mmc@ reminded me that I had been slacking on getting this into the tree.
> > > 
> > > This patch updates LLVM to version 3.7, using GCC from ports as a
> > > compiler, and using its headers and libstdc++ at runtime.  The downside
> > > is, of course, that everything compiled with clang++ will now depend on
> > > libstdc++ from ports.  But until we have libc++, there is really nothing
> > > else we can do.  Having a modern LLVM with a complete C++11 featureset
> > > is more important.
> > > 
> > > Works on amd64, i386 and sparc64.  powerpc and mips64 are still WIP,
> > > both upstream and portwise.
> > > 
> > > The patch below is only the update itself.  This also needs patches to
> > > gcc4.port.mk as well as clang.port.mk to integrate the new libstdc++
> > > logic.  I will send these shortly.
> > 
> > I've been running this for weeks and have used it for some big builds.
> > No apparent problems. ok mmcc@
> > 
> 
> What testing has been done so far in the ports tree?
> 
> 

I have done manual builds of some ports that use clang (various
firefoxes, multimedia stuff, vlc, mplayer), but maybe this needs a bulk
build?

Re: update: devel/llvm

2015-11-11 Thread Landry Breuil 
On Wed, Nov 11, 2015 at 05:32:35PM +, Stuart Henderson wrote:
> On 2015/11/11 10:26, Michael McConville wrote:
> > Pascal Stumpf wrote:
> > > mmc@ reminded me that I had been slacking on getting this into the tree.
> > > 
> > > This patch updates LLVM to version 3.7, using GCC from ports as a
> > > compiler, and using its headers and libstdc++ at runtime.  The downside
> > > is, of course, that everything compiled with clang++ will now depend on
> > > libstdc++ from ports.  But until we have libc++, there is really nothing
> > > else we can do.  Having a modern LLVM with a complete C++11 featureset
> > > is more important.
> > > 
> > > Works on amd64, i386 and sparc64.  powerpc and mips64 are still WIP,
> > > both upstream and portwise.
> > > 
> > > The patch below is only the update itself.  This also needs patches to
> > > gcc4.port.mk as well as clang.port.mk to integrate the new libstdc++
> > > logic.  I will send these shortly.
> > 
> > I've been running this for weeks and have used it for some big builds.
> > No apparent problems. ok mmcc@
> > 
> 
> What testing has been done so far in the ports tree?
> 

+1 here. Even if i really want us to move to upstream llvm instead of
the monster we have now, it has to go into several bulks, and the
resulting pkgs have to be tested at runtime for regressions. You dont
want to be the one breaking mozilla or webkit or kde or half of the
ports-tree now requiring decent compilers..

Landry

Re: update: devel/llvm

2015-11-11 Thread Michael McConville 
Pascal Stumpf wrote:
> mmc@ reminded me that I had been slacking on getting this into the tree.
> 
> This patch updates LLVM to version 3.7, using GCC from ports as a
> compiler, and using its headers and libstdc++ at runtime.  The downside
> is, of course, that everything compiled with clang++ will now depend on
> libstdc++ from ports.  But until we have libc++, there is really nothing
> else we can do.  Having a modern LLVM with a complete C++11 featureset
> is more important.
> 
> Works on amd64, i386 and sparc64.  powerpc and mips64 are still WIP,
> both upstream and portwise.
> 
> The patch below is only the update itself.  This also needs patches to
> gcc4.port.mk as well as clang.port.mk to integrate the new libstdc++
> logic.  I will send these shortly.

I've been running this for weeks and have used it for some big builds.
No apparent problems. ok mmcc@

Re: update: devel/llvm

2015-11-11 Thread Christian Weisgerber 
Pascal Stumpf:

> I have done manual builds of some ports that use clang (various
> firefoxes, multimedia stuff, vlc, mplayer), but maybe this needs a bulk
> build?

If I get a complete patch, I can kick off an amd64 bulk build with it
tom^Hday.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de