Re: [HEADS UP] Clang 8.0.0 upgrade on 13.0-CURRENT
Robert Huff writes: > Charlie Li writes: > >> The LLVM ports are still needed for those consumers that need their >> components, such as llvm-config and the like. Please refer to the aptly >> named wiki page again: >> https://wiki.freebsd.org/WhyDoIHaveToBuildLLVMWhenIAlreadyHaveClangInstalled > > This was the thing I thinking about. > >> Think of it this way: the base system toolchain is *based on* some >> released version of LLVM (or GCC) as of a particular revision of >> base/. "Based on" means that components that are not critical to >> the actual functioning of the toolchain or otherwise useful to >> FreeBSD itself are bound to be stripped away when included and >> integrated in the base system. > > That may be the path of wisdom; and I understand keeping things > working is a non-trivial job, for which I thank those who do it. > Please understand my ... frustration ... in having to deal with > the conseqences, particularly with regard to the ongoing drm changes. > To return to my original point, this is why I suggested an entry in > ports/UPDATING - to let others in my position know of possible > impact. If you want to avoid duplication don't build/install base Clang e.g., $ echo 'WITHOUT_TOOLCHAIN=1' >>/etc/src.conf $ make delete-old -C/usr/src $ pkg install llvm80 $ ln -s clang80 /usr/local/bin/cc $ ln -s clang++80 /usr/local/bin/c++ $ ln -s clang-cpp80 /usr/local/bin/cpp ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
powerpc64: devel/qt5-core build fails with: "Q_ATOMIC_INT64_IS_SUPPORTED must be defined on a 64-bit platform", more
The below is from a ports-mgmt/poudriere-devel run under FreeBSD head -r344825 on an old PowerMac G5 (2 sockets, 2 cores each, powerpc64). The /usr/ports is from head -r494751 . buildworld buildkernel was via devel/powerpc64-xtoolchain-gcc materials and system-clang (8.0.0) was built (and installed as cc) as part of that. /usr/ports/base/binutils was used to supply the system binutils, including ld. (Running the PowerPC G5 for this context does require some hacks in /usr/src/ currently.) --- .obj/qatomic.o --- g++8 -c -O2 -pipe -g -Wl,-rpath=/usr/local/lib/gcc8 -Wl,-rpath=/usr/local/lib/gcc8 -Og -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -pthread -fPIC -DQT_GLIB -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x05 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I. -I../3rdparty/zlib/src -Iglobal -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I../3rdparty/sha3 -I../3rdparty -I../3rdparty/double-conversion/include -I../3rdparty/double-conversion/include/double-conversion -I../3rdparty/forkfd -I../3rdparty/tinycbor/src -I../../include -I../../include/QtCore -I../../include/QtCore/5.12.1 -I../../include/QtCore/5.12.1/QtCore -I.moc -I.tracegen -isystem /usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -isystem /usr/local/include -I/u sr/local/lib/qt5/mkspecs/freebsd-g++ -o .obj/qatomic.o thread/qatomic.cpp thread/qatomic.cpp:1624:4: error: #error "Q_ATOMIC_INT64_IS_SUPPORTED must be defined on a 64-bit platform" # error "Q_ATOMIC_INT64_IS_SUPPORTED must be defined on a 64-bit platform" ^ In file included from ../../include/QtCore/qglobal.h:1, from thread/qatomic.h:41, from thread/qatomic.cpp:41: ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h: In instantiation of 'class QBasicAtomicInteger': ../../include/QtCore/../../src/corelib/thread/qatomic.h:55:7: required from 'class QAtomicInteger' thread/qatomic.cpp:1631:1: required from here ../../include/QtCore/../../src/corelib/global/qglobal.h:121:63: error: static assertion failed: template parameter is an integral of a size not supported on this platform # define Q_STATIC_ASSERT_X(Condition, Message) static_assert(bool(Condition), Message) ^~~ ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:97:5: note: in expansion of macro 'Q_STATIC_ASSERT_X' Q_STATIC_ASSERT_X(QAtomicOpsSupport::IsSupported, "template parameter is an integral of a size not supported on this platform"); ^ ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h: In instantiation of 'class QBasicAtomicInteger': ../../include/QtCore/../../src/corelib/thread/qatomic.h:55:7: required from 'class QAtomicInteger' thread/qatomic.cpp:1632:1: required from here ../../include/QtCore/../../src/corelib/global/qglobal.h:121:63: error: static assertion failed: template parameter is an integral of a size not supported on this platform # define Q_STATIC_ASSERT_X(Condition, Message) static_assert(bool(Condition), Message) ^~~ ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:97:5: note: in expansion of macro 'Q_STATIC_ASSERT_X' Q_STATIC_ASSERT_X(QAtomicOpsSupport::IsSupported, "template parameter is an integral of a size not supported on this platform"); ^ ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h: In instantiation of 'class QBasicAtomicInteger': ../../include/QtCore/../../src/corelib/thread/qatomic.h:55:7: required from 'class QAtomicInteger' thread/qatomic.cpp:1633:1: required from here ../../include/QtCore/../../src/corelib/global/qglobal.h:121:63: error: static assertion failed: template parameter is an integral of a size not supported on this platform # define Q_STATIC_ASSERT_X(Condition, Message) static_assert(bool(Condition), Message) ^~~ ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:97:5: note: in expansion of macro 'Q_STATIC_ASSERT_X' Q_STATIC_ASSERT_X(QAtomicOpsSupport::IsSupported, "template parameter is an integral of a size not supported on this platform"); ^ ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h: In instantiation of 'class QBasicAtomicInteger': ../../include/QtCore/../../src/corelib/thread/qatomic.h:55:7: required from 'class QAtomicInteger' thread/qatomic.cpp:1634:1: required from here ../../include/QtCore/../../src/corelib/global/qglobal.h:121:63: error: static assertion failed: template parameter is an integral of a size not supported o
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ audio/oss | 4.2-build2017 | 4.2-build2019 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
powerpc64 head -r344825: system-clang (8.0.0) asserts compiling mesa-dri-18.3.2_2's glsl/ir_clone.cpp: "Target supports vector op, but scalar requires expansion?"
The below is from a ports-mgmt/poudriere-devel run under FreeBSD head
-r344825 on an old PowerMac G5 (2 sockets, 2 cores each, powerpc64).
The /usr/ports is from head -r494751 . buildworld buildkernel
was via devel/powerpc64-xtoolchain-gcc materials and system-clang
(8.0.0) was built (and installed as cc/c++) as part of that.
/usr/ports/base/binutils was used to supply the system binutils,
including ld. (Running the PowerPC G5 for this context does require
some hacks in /usr/src/ currently.)
Being a poudriere-devel run, the /tmp/nir_constant_expressions-be5a21.*
are not available (not recorded in the tar of the failure). (Too
bad there is a mismatch betting poudriere's capture and where such
files are placed.)
But I do have a gdb based backtrace from the:
work/mesa-18.3.2/src/compiler/cc.15701.core
The assert was the one in:
case ISD::FTRUNC: {
// We're going to widen this vector op to a legal type by padding with undef
// elements. If the wide vector op is eventually going to be expanded to
// scalar libcalls, then unroll into scalar ops now to avoid unnecessary
// libcalls on the undef elements. We are assuming that if the scalar op
// requires expanding, then the vector op needs expanding too.
EVT VT = N->getValueType(0);
if (TLI.isOperationExpand(N->getOpcode(), VT.getScalarType())) {
EVT WideVecVT = TLI.getTypeToTransformTo(*DAG.getContext(), VT);
assert(!TLI.isOperationLegalOrCustom(N->getOpcode(), WideVecVT) &&
"Target supports vector op, but scalar requires expansion?");
Res = DAG.UnrollVectorOp(N, WideVecVT.getVectorNumElements());
break;
}
(gdb) info threads
Id Target Id Frame
* 1LWP 1001190x137251e8 in .__sys_thr_kill () at
thr_kill.S:3
(gdb) bt
#0 0x137251e8 in .__sys_thr_kill () at thr_kill.S:3
#1 0x137247bc in __raise (s=) at
/usr/src/lib/libc/gen/raise.c:52
#2 0x136e6410 in abort () at /usr/src/lib/libc/stdlib/abort.c:79
#3 0x13712fd8 in __assert (func=, file=,
line=, failedexpr=) at
/usr/src/lib/libc/gen/assert.c:51
#4 0x1351f20c in llvm::DAGTypeLegalizer::WidenVectorResult () at
/usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp:2531
#5 0x12f1d7d8 in llvm::DAGTypeLegalizer::run () at
/usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:281
#6 0x12f1eab4 in llvm::SelectionDAG::LegalizeTypes () at
/usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:1115
#7 0x12db9e50 in llvm::SelectionDAGISel::CodeGenAndEmitDAG () at
/usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:776
#8 0x12dbf934 in llvm::SelectionDAGISel::SelectAllBasicBlocks () at
/usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1784
#9 0x12dc2668 in llvm::SelectionDAGISel::runOnMachineFunction () at
/usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:471
#10 0x120edfc8 in runOnMachineFunction () at
/usr/src/contrib/llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp:155
#11 0x130514b4 in llvm::MachineFunctionPass::runOnFunction () at
/usr/src/contrib/llvm/lib/CodeGen/MachineFunctionPass.cpp:74
#12 0x1296d640 in llvm::FPPassManager::runOnFunction () at
/usr/src/contrib/llvm/lib/IR/LegacyPassManager.cpp:1644
#13 0x1296d908 in llvm::FPPassManager::runOnModule () at
/usr/src/contrib/llvm/lib/IR/LegacyPassManager.cpp:1679
#14 0x1296e780 in runOnModule () at
/usr/src/contrib/llvm/lib/IR/LegacyPassManager.cpp:1744
#15 llvm::legacy::PassManagerImpl::run () at
/usr/src/contrib/llvm/lib/IR/LegacyPassManager.cpp:1857
#16 0x10bbac7c in EmitAssembly () at
/usr/src/contrib/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:882
#17 0x10bbc9a8 in clang::EmitBackendOutput () at
/usr/src/contrib/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:1318
#18 0x103cd0b0 in clang::BackendConsumer::HandleTranslationUnit () at
/usr/src/contrib/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:295
#19 0x10821d40 in clang::ParseAST () at
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseAST.cpp:170
#20 0x1080d528 in clang::ASTFrontendAction::ExecuteAction () at
/usr/src/contrib/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:1037
#21 0x103cc108 in clang::CodeGenAction::ExecuteAction () at
/usr/src/contrib/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:1048
#22 0x10811eb0 in clang::FrontendAction::Execute () at
/usr/src/contrib/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:935
#23 0x111b1960 in clang::CompilerInstance::ExecuteAction () at
/usr/src/contrib/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:955
#24 0x103b602c in clang::ExecuteCompilerInvocation () at
/usr/src/contrib/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:268
#25 0x103a47c8 in cc1_main () at
/usr/src/contrib/llvm/tools/clang/tools/driver/cc1_main.cpp:219
#
Django versions
I'm working on a port for mailman 3. I want to use django 2.1 because that's what I'm using on the systems I'm currently running mailman 2 on you can't really run different version of django on the same system). But it turns out a lot of ports have RUN_DEPENDS for www/py-django111. One possible solution would be to change these dependencies to the www/py-django meta port. This allows the user pick the version of django via py-django options. But I see a bunch of ports got added last month: www/py-dj21-django-cors-headers www/py-dj21-django-debug-toolbar www/py-dj21-django-filter www/py-dj21-django-js-asset www/py-dj21-django-mptt www/py-dj21-django-tables2 www/py-dj21-django-taggit www/py-dj21-django-taggit-serializer www/py-dj21-django-timezone-field www/py-dj21-djangorestframework www/py-dj21-drf-yasg which are the py-django21 version of the py-django111 ports with similar names. Anyway the current situation prevents folks from using py-django20 if that's what they want. And a ton of changes will be needed when django22 (currently in beta) arrives. The downside I see to changing dependencies from py-django111 to py-django is that only the py-django111 versions of things were get built/tested automatically (due to py-django111 being the default version). And I think there are issues for ports that don't work with all version of django (is there a way for a port's Makefile to know what version of django got installed?) Are there other problems? Are there other solutions? Flavors comes to mind but I'm told "doubly flavored" ports (python flavor vs. django flavor) are very difficult. Without any changes I'll need to add DJANGO111 and DJANGO21 to my mailman 3 port and forget about folks being able to use django20. This will be extra messy because mailman 3 is split across several different packages. Craig ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Django versions
On Thu, Mar 7, 2019 at 8:14 AM Craig Leres wrote: > > I'm working on a port for mailman 3. I want to use django 2.1 because > that's what I'm using on the systems I'm currently running mailman 2 on > you can't really run different version of django on the same system). > But it turns out a lot of ports have RUN_DEPENDS for www/py-django111. > > One possible solution would be to change these dependencies to the > www/py-django meta port. This allows the user pick the version of django > via py-django options. But I see a bunch of ports got added last month: > > www/py-dj21-django-cors-headers > www/py-dj21-django-debug-toolbar > www/py-dj21-django-filter > www/py-dj21-django-js-asset > www/py-dj21-django-mptt > www/py-dj21-django-tables2 > www/py-dj21-django-taggit > www/py-dj21-django-taggit-serializer > www/py-dj21-django-timezone-field > www/py-dj21-djangorestframework > www/py-dj21-drf-yasg > > which are the py-django21 version of the py-django111 ports with similar > names. > > Anyway the current situation prevents folks from using py-django20 if > that's what they want. And a ton of changes will be needed when django22 > (currently in beta) arrives. > > The downside I see to changing dependencies from py-django111 to > py-django is that only the py-django111 versions of things were get > built/tested automatically (due to py-django111 being the default > version). And I think there are issues for ports that don't work with > all version of django (is there a way for a port's Makefile to know what > version of django got installed?) > > Are there other problems? > > Are there other solutions? Flavors comes to mind but I'm told "doubly > flavored" ports (python flavor vs. django flavor) are very difficult. > > Without any changes I'll need to add DJANGO111 and DJANGO21 to my > mailman 3 port and forget about folks being able to use django20. This > will be extra messy because mailman 3 is split across several different > packages. Hi, Please don't use the django metaport, this port should be removed and people should stop using hacks. Someone needs to integrate a USE_PYTHON=django in python.mk Antoine ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Django versions
On 07/03/2019 01:55, Craig Leres wrote: > I'm working on a port for mailman 3. I want to use django 2.1 because > that's what I'm using on the systems I'm currently running mailman 2 on > you can't really run different version of django on the same system). > But it turns out a lot of ports have RUN_DEPENDS for www/py-django111. > I've been working on mail/mailman3 for over a year now (holy crap), which is still in phab as D14126. It is only the core engine however. Upstream Mailman have architected things such that anything outside of the core engine are officially optional. Thus, it is probably best to have the other parts, like the Django-consuming parts, as their own ports, like mail/mailman3-portorius and mail/mailman3-hyperkitty. -- Charlie Li …nope, still don't have an exit line. (This email address is for mailing list use; replace local-part with vishwin for off-list communication if possible) signature.asc Description: OpenPGP digital signature
