Re: assembler error on trying to port OpenBLAS
On Fri, Oct 30, 2020 at 04:55:53PM +, Stuart Henderson wrote: > On 2020/10/29 20:25, Aisha Tammy wrote: > > I'm trying to port OpenBLAS to the tree and am currently getting > > some weird assembler errors (port makefile is attached at end math/openblas) > > not that weird, the source code has inline asm, it is passed to > /usr/bin/as which is pretty old and pre-dates support for this > being added > > > Presumably this is happening due to the assembler being used is > > the one from base as we don't build the ports egcc with gas for > > anything except aarch64 and arm. > > I'm kind of stumped here as it seems like using gfortran sets the > > compiler to egcc (compiling the above file with cc works). > > Is it possible to mix gfortran with base-clang C compiler? > > Another (possible) solution would be to build egcc all archs with > > the new gas assembler, but that sounds a lot more dangerous and I > > don't know enough to know if that is possible/or even a good idea/ > > or if it will even work :-/ > > I think ports/lang/gcc should start using the newer version of gas > from ports on i386 and amd64. > > On these archs it doesn't affect many ports (fortran things, > asterisk, seabios [vmm-firmware], maybe one or two others). > > For other archs there is higher risk as large parts of the ports > tree use ports-gcc on most of these. But there's probably less need > for the newer assembler on those too. I had sent a diff like the following to Pascal last year. Since in the past we had run into issues with inline asm and our GNU as being too old. Index: Makefile === RCS file: /home/cvs/ports/lang/gcc/8/Makefile,v retrieving revision 1.34 diff -u -p -u -p -r1.34 Makefile --- Makefile4 Sep 2020 09:55:34 - 1.34 +++ Makefile31 Oct 2020 03:08:05 - @@ -18,6 +18,7 @@ DPB_PROPERTIES = parallel V = 8.4.0 FULL_VERSION = $V FULL_PKGVERSION = $V +REVISION = 0 ADASTRAP-amd64 = adastrap-amd64-8.3.0-2.tar.xz ADASTRAP-arm = adastrap-arm-4.9.4-0.tar.xz @@ -65,7 +66,8 @@ EXTRACT_ONLY =${DISTNAME}.tar.xz BUILD_DEPENDS += devel/bison \ devel/libexecinfo -.if ${MACHINE_ARCH} == "aarch64" || ${MACHINE_ARCH} == "arm" +.if ${MACHINE_ARCH} == "aarch64" || ${MACHINE_ARCH} == "amd64" || \ +${MACHINE_ARCH} == "arm" || ${MACHINE_ARCH} == "i386" BUILD_DEPENDS += devel/gas RUN_DEPENDS += devel/gas RUN_DEPENDS-main +=devel/gas
Re: UPDATE: Boost 1.70
On Fri Oct 30, 2020 at 09:04:53PM -0400, Daniel Dickman wrote: > > > > > > games/pokerth > > > > In file included from ../src/net/common/chatcleanermanager.cpp:32: > > In file included from ../src/net/chatcleanermanager.h:36: > > In file included from /usr/local/include/boost/asio.hpp:24: > > In file included from > > /usr/local/include/boost/asio/basic_datagram_socket.hpp:20: > > In file included from /usr/local/include/boost/asio/basic_socket.hpp:27: > > In file included from /usr/local/include/boost/asio/executor.hpp:338: > > /usr/local/include/boost/asio/impl/executor.hpp:179:22: error: no member > > named 'context' in 'std::__1::reference_wrapper' > > > > > > Think diff below might fix this one. Sourced from archlinux. > > With this I was able to check that the game starts up. > > Index: Makefile > === > RCS file: /cvs/ports/games/pokerth/Makefile,v > retrieving revision 1.47 > diff -u -p -u -r1.47 Makefile > --- Makefile 20 Mar 2020 16:44:23 - 1.47 > +++ Makefile 31 Oct 2020 00:48:37 - > @@ -5,7 +5,7 @@ COMMENT= texas hold'em poker game with o > BROKEN-hppa =needs atomic ops > > DISTNAME = pokerth-1.1.2 > -REVISION = 5 > +REVISION = 6 > > CATEGORIES= games x11 > > Index: > patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_connection_hpp > === > RCS file: > patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_connection_hpp > diff -N > patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_connection_hpp > --- /dev/null 1 Jan 1970 00:00:00 - > +++ > patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_connection_hpp >31 Oct 2020 00:48:37 - > @@ -0,0 +1,29 @@ > +$OpenBSD$ > + If you commit this diff, please add a quick comment here. Thanks! > +Index: src/third_party/websocketpp/websocketpp/transport/asio/connection.hpp > +--- > src/third_party/websocketpp/websocketpp/transport/asio/connection.hpp.orig > src/third_party/websocketpp/websocketpp/transport/asio/connection.hpp > +@@ -311,9 +311,10 @@ class connection : public config::socket_type::socket_ > + * needed. > + */ > + timer_ptr set_timer(long duration, timer_handler callback) { > +-timer_ptr new_timer = lib::make_shared( > +-lib::ref(*m_io_service), > +-lib::asio::milliseconds(duration) > ++timer_ptr new_timer( > ++new lib::asio::steady_timer( > ++*m_io_service, > ++lib::asio::milliseconds(duration)) > + ); > + > + if (config::enable_multithreading) { > +@@ -461,8 +462,7 @@ class connection : public config::socket_type::socket_ > + m_io_service = io_service; > + > + if (config::enable_multithreading) { > +-m_strand = lib::make_shared( > +-lib::ref(*io_service)); > ++m_strand.reset(new lib::asio::io_service::strand(*io_service)); > + } > + > + lib::error_code ec = socket_con_type::init_asio(io_service, > m_strand, > Index: > patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_endpoint_hpp > === > RCS file: > patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_endpoint_hpp > diff -N > patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_endpoint_hpp > --- /dev/null 1 Jan 1970 00:00:00 - > +++ > patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_endpoint_hpp > 31 Oct 2020 00:48:37 - > @@ -0,0 +1,36 @@ > +$OpenBSD$ > + > +Index: src/third_party/websocketpp/websocketpp/transport/asio/endpoint.hpp > +--- src/third_party/websocketpp/websocketpp/transport/asio/endpoint.hpp.orig > src/third_party/websocketpp/websocketpp/transport/asio/endpoint.hpp > +@@ -191,8 +191,7 @@ class endpoint : public config::socket_type { (public) > + > + m_io_service = ptr; > + m_external_io_service = true; > +-m_acceptor = lib::make_shared( > +-lib::ref(*m_io_service)); > ++m_acceptor.reset(new lib::asio::ip::tcp::acceptor(*m_io_service)); > + > + m_state = READY; > + ec = lib::error_code(); > +@@ -660,9 +659,7 @@ class endpoint : public config::socket_type { (public) > + * @since 0.3.0 > + */ > + void start_perpetual() { > +-m_work = lib::make_shared( > +-lib::ref(*m_io_service) > +-); > ++m_work.reset(new lib::asio::io_service::work(*m_io_service)); > + } > + > + /// Clears the endpoint's perpetual flag, allowing it to exit when empty > +@@ -826,8 +823,7 @@ class endpoint : public config::socket_type { (public) > + > + // Create a resolver > + if (!m_resolver) { > +-m_resolver = lib::make_shared( > +-lib::r
mips64 bulk build report
bulk build on octeon.ports.openbsd.org started on Thu Oct 22 16:11:31 UTC 2020 finished at Tue Oct 27 11:25:51 UTC 2020 lasted 05D19h14m done with kern.version=OpenBSD 6.8-current (GENERIC.MP) #13: Thu Oct 22 15:54:26 UTC 2020 built packages:8589 Oct 22:2110 Oct 23:1209 Oct 24:783 Oct 25:604 Oct 26:1022 Oct 27:2860 build failures: 27 http://build-failures.rhaalovely.net/mips64/2020-10-22/cad/netgen.log http://build-failures.rhaalovely.net/mips64/2020-10-22/chinese/libchewing.log http://build-failures.rhaalovely.net/mips64/2020-10-22/chinese/libpinyin.log http://build-failures.rhaalovely.net/mips64/2020-10-22/databases/postgresql-pllua.log http://build-failures.rhaalovely.net/mips64/2020-10-22/devel/coccinelle.log http://build-failures.rhaalovely.net/mips64/2020-10-22/devel/libexecinfo.log http://build-failures.rhaalovely.net/mips64/2020-10-22/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net/mips64/2020-10-22/emulators/openmsx.log http://build-failures.rhaalovely.net/mips64/2020-10-22/games/astromenace.log http://build-failures.rhaalovely.net/mips64/2020-10-22/games/hyperrogue.log http://build-failures.rhaalovely.net/mips64/2020-10-22/geo/gpstk.log http://build-failures.rhaalovely.net/mips64/2020-10-22/geo/spatialite/gui.log http://build-failures.rhaalovely.net/mips64/2020-10-22/inputmethods/scim-fcitx.log http://build-failures.rhaalovely.net/mips64/2020-10-22/lang/STk.log http://build-failures.rhaalovely.net/mips64/2020-10-22/lang/gforth.log http://build-failures.rhaalovely.net/mips64/2020-10-22/lang/librep.log http://build-failures.rhaalovely.net/mips64/2020-10-22/lang/pfe.log http://build-failures.rhaalovely.net/mips64/2020-10-22/lang/squeak/vm.log http://build-failures.rhaalovely.net/mips64/2020-10-22/math/gbc.log http://build-failures.rhaalovely.net/mips64/2020-10-22/math/ntl.log http://build-failures.rhaalovely.net/mips64/2020-10-22/multimedia/frei0r-plugins.log http://build-failures.rhaalovely.net/mips64/2020-10-22/plan9/drawterm.log http://build-failures.rhaalovely.net/mips64/2020-10-22/security/botan2.log http://build-failures.rhaalovely.net/mips64/2020-10-22/shells/ksh93.log http://build-failures.rhaalovely.net/mips64/2020-10-22/sysutils/libvirt.log http://build-failures.rhaalovely.net/mips64/2020-10-22/sysutils/u-boot,aarch64.log http://build-failures.rhaalovely.net/mips64/2020-10-22/x11/e17/elementary.log
UPDATE: libsndfile 1.0.30 - CVE
Here is an update to libsndfile 1.0.30. CVE-2017-12562, CVE-2017-17456, CVE-2017-17457, CVE-2018-19661, CVE-2018-19662, CVE-2018-19758 and CVE-2019-3832. Index: Makefile === RCS file: /cvs/ports/audio/libsndfile/Makefile,v retrieving revision 1.33 diff -u -p -u -p -r1.33 Makefile --- Makefile12 Jul 2019 20:43:35 - 1.33 +++ Makefile31 Oct 2020 05:07:55 - @@ -2,31 +2,33 @@ COMMENT= library to handle various audio file formats -DISTNAME= libsndfile-1.0.28 +DISTNAME= libsndfile-1.0.30 CATEGORIES=audio +GH_ACCOUNT=libsndfile +GH_PROJECT=libsndfile +GH_TAGNAME=v1.0.30 + HOMEPAGE= http://www.mega-nerd.com/libsndfile/ + MAINTAINER=Jan Stary -SHARED_LIBS += sndfile 6.0 # .1.28 + +SHARED_LIBS += sndfile 7.0 # .1.28 # LGPLv2.1 PERMIT_PACKAGE=Yes -MASTER_SITES= ${HOMEPAGE}files/ +WANTLIB= c m sndio FLAC ogg opus vorbis vorbisenc -WANTLIB= c m sndio FLAC ogg vorbis vorbisenc +MODULES= devel/cmake -CONFIGURE_STYLE=gnu -CONFIGURE_ARGS=--disable-alsa \ - --disable-octave \ - --disable-sqlite - -CONFIGURE_ENV= CPPFLAGS="-I${PREFIX}/include" -MODGNU_CONFIG_GUESS_DIRS=${WRKSRC}/Cfg +CONFIGURE_ARGS=-DBUILD_SHARED_LIBS:BOOL=ON \ + -DCMAKE_DISABLE_FIND_PACKAGE_ALSA:BOOL=True \ + -DCMAKE_DISABLE_FIND_PACKAGE_Speex:BOOL=True \ + -DCMAKE_DISABLE_FIND_PACKAGE_SQLite3:BOOL=True LIB_DEPENDS= audio/flac \ audio/libogg \ - audio/libvorbis - -FAKE_FLAGS=htmldocdir=${PREFIX}/share/doc/libsndfile + audio/libvorbis \ + audio/opus .include Index: distinfo === RCS file: /cvs/ports/audio/libsndfile/distinfo,v retrieving revision 1.17 diff -u -p -u -p -r1.17 distinfo --- distinfo23 Apr 2018 08:48:54 - 1.17 +++ distinfo31 Oct 2020 05:07:55 - @@ -1,2 +1,2 @@ -SHA256 (libsndfile-1.0.28.tar.gz) = H/M5KfBC+jM67R6JI6pijD7p4euFUSaGxVCS0eWp36k= -SIZE (libsndfile-1.0.28.tar.gz) = 1202833 +SHA256 (libsndfile-1.0.30.tar.gz) = WUK5Y9HbPtirH/uFcIMiqpY333bZ/oTh3+Sal6kOj0c= +SIZE (libsndfile-1.0.30.tar.gz) = 650659 Index: patches/patch-CMakeLists_txt === RCS file: patches/patch-CMakeLists_txt diff -N patches/patch-CMakeLists_txt --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-CMakeLists_txt31 Oct 2020 05:07:55 - @@ -0,0 +1,21 @@ +$OpenBSD$ + +Index: CMakeLists.txt +--- CMakeLists.txt.orig CMakeLists.txt +@@ -56,6 +56,7 @@ if (MSVC AND (CMAKE_VERSION VERSION_LESS 3.15)) + endif () + option (ENABLE_PACKAGE_CONFIG "Generate and install package config file" ON) + option (INSTALL_PKGCONFIG_MODULE "Generate and install pkg-config module" ON) ++option (INSTALL_MANPAGES "Install man pages for programs" ON) + + list (APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake") + +@@ -74,7 +75,6 @@ if (NOT ENABLE_CPU_CLIP) + set (CPU_CLIPS_NEGATIVE FALSE) + endif () + cmake_dependent_option (ENABLE_COMPATIBLE_LIBSNDFILE_NAME "Set DLL name to libsndfile-1.dll (canonical name), sndfile.dll otherwise" OFF "WIN32;BUILD_SHARED_LIBS" OFF) +-cmake_dependent_option (INSTALL_MANPAGES "Install man pages for programs" ON "BUILD_PROGRAMS AND (UNIX OR MINGW OR CYGWIN)" OFF) + + set (HAVE_EXTERNAL_XIPH_LIBS ${ENABLE_EXTERNAL_LIBS}) + set (HAVE_SQLITE3 ${BUILD_REGTEST}) Index: patches/patch-configure === RCS file: patches/patch-configure diff -N patches/patch-configure --- patches/patch-configure 23 Apr 2018 08:48:54 - 1.3 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,16 +0,0 @@ -$OpenBSD: patch-configure,v 1.3 2018/04/23 08:48:54 jca Exp $ - -Some compilers don't have -Wvla - -Index: configure configure.orig -+++ configure -@@ -20828,7 +20828,7 @@ rm -f core conftest.err conftest.$ac_objext \ - common_flags="-Wcast-align -Wcast-qual -Wshadow -Wwrite-strings -Wundef -Wuninitialized -Winit-self" - - # -Winline -Wconversion " -- CFLAGS="$CFLAGS $common_flags -Wbad-function-cast -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Waggregate-return -Wvla" -+ CFLAGS="$CFLAGS $common_flags -Wbad-function-cast -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Waggregate-return" - CXXFLAGS="$CXXFLAGS $common_flags -Wctor-dtor-privacy -Wnon-virtual-dtor -Woverloaded-virtual -Wreorder -Wsign-promo" - - if test "x$enable_gcc_opt" = "xno" ; then Index: pkg/PLIST === RCS file: /cvs/ports/audio/libsndfile/pkg/PLIST,v retrieving revision 1.13 diff -u -p -u -p -r1.13 PLIST --- pkg/PLIST 23 A
Re: NEW: net/i2p
On Fri Oct 30, 2020 at 07:11:26PM +0100, Solene Rapenne wrote: > On Sat, 24 Oct 2020 17:06:41 - > "Dimitri Karamazov" : > > > Ping > > Both ports looks fine to me. > > Now someone else need to review the ports and give their OK so we > can import the ports into the tree. > OK rsadowski@
Re: 回复: 回复: pysol doesn't run
Thank you, I shall look into it and create the new port for py-sol-card. wen 发件人: Daniel Dickman 发送时间: 2020年10月30日 12:03 收件人: wen heping 抄送: Daniel Dickman ; Carsten Boysen Jensen ; ports@openbsd.org 主题: Re: 回复: 回复: pysol doesn't run On Thu, 29 Oct 2020, wen heping wrote: > Here is the patch to update games/pysol to 2.10.1. > > wen > Hi Wen, please try running "pysol". What happens? :-) (See my previous notes on needing a new port for pysol_cards)
Re: New: fna - FNA framework for fnaify games
re-ping On Tue, Oct 20, 2020 at 04:46:32AM -0600, Thomas Frohwein wrote: > ping > > On Thu, Oct 08, 2020 at 03:46:01AM -0600, Thomas Frohwein wrote: > > Hi, > > > > This is a port of the .NET FNA libraries - the core FNA.dll, as well as > > the XNA bridge files. Until recently, games/fnaify was mostly able to > > use whatever version of FNA.dll came bundled with the games. However, > > the recent update to graphics/mojoshader with API change, has made that > > largely impossible. > > > > At this point, most of the games in the fnaify catalogue run with FNA > > 20.09 and mojoshader in the ports. Therefore, I would like to switch > > the strategy for handling the FNA.dll file from the bundled one to one > > in ${LOCALBASE}/share/FNA/. > > > > fnaify is already looking for an existing FNA.dll in this directory > > since the 3.0 update. > > > > This port can be tested with latest fnaify, for example with the free > > XNA game Chaos Heart that can be downloaded at [1]. > > > > The port includes FNA.NetStub and Vorbisfile-CS from their GitHub > > repos, following the example of emulators/ppsspp for including the > > additional sources. In addition, a customization of the build in > > FNA.Settings.props is included that provides SDL2-image and Vorbisfile > > bindings for broader compatibility. > > > > ok? > > > > [1] http://www.mattmakesgames.com/ > >
Re: Unmaze Qt4 from x11/qwt
On Fri Mar 13, 2020 at 09:58:29PM +0100, Rafael Sadowski wrote: > Is anyone willing to make x11/qwt qt5 only without -common etc.? The > difficult part is to set the right @pkgpath/@conflict.. foo and thus > enable a pkg_add update. > > No more customers available for the Qt4 (main) parts, only Qt5. > > I'm looking forward to test diff. > > Rafael Sadowski > Here is my final version. I've adjusted gnuradio and qgis. The pkg_add upgrade process looks ok, right? $ TRUSTED_PKG_PATH=/usr/ports/packages/amd64/all pkg_add -u boost-1.67.0p1->1.67.0p1: ok gnuradio-3.8.2.0p0:python-3.8.6p0->3.8.6p0: ok qwt-6.1.3p2-qt5+qwt-common-6.1.3p2->qwt-6.1.5 forward dependencies: | Dependency of gnuradio-3.8.2.0 on qwt-*-qt5 doesn't match | Dependency of qgis-3.16.0 on qwt-*-qt5 doesn't match Merging gnuradio-3.8.2.0->3.8.2.0p0 (ok) Merging qgis-3.16.0->3.16.0p0 (ok) gnuradio-3.8.2.0p0+qgis-3.1...:qtconnectivity-5.13.2->5.13.2: ok gnuradio-3.8.2.0p0+qgis-3.1...:py3-qt5-5.13.2p0->5.13.2p0: ok gnuradio-3.8.2.0p0+qgis-3.1...:qscintilla-2.11.4p2->2.11.4p2: ok gnuradio-3.8.2.0p0+qgis-3.1...:py3-qscintilla-2.11.4p3->2.11.4p3: ok gnuradio-3.8.2.0+qgis-3.16.0+qwt-6.1.3p2-qt5+qwt-common-6.1.3p2->gnuradio-3.8.2.0p0+qgis-3.16.0p0+qwt-6.1.5: ok Running tags: ok Feedback, concerns? Rafael diff --git a/comms/gnuradio/Makefile b/comms/gnuradio/Makefile index 12bb35dc35a..7a2c371847c 100644 --- a/comms/gnuradio/Makefile +++ b/comms/gnuradio/Makefile @@ -4,6 +4,7 @@ COMMENT = signal-processing toolkit for SDR (software-defined radio) V =3.8.2.0 DISTNAME = gnuradio-$V +REVISION = 0 SHARED_LIBS += gnuradio-analog 0.0 # 3.7 SHARED_LIBS += gnuradio-atsc 0.0 # 3.7 @@ -41,7 +42,7 @@ WANTLIB += Qt5Core Qt5Gui Qt5Widgets SDL boost_atomic-mt boost_chrono-mt WANTLIB += boost_date_time-mt boost_filesystem-mt boost_program_options-mt WANTLIB += boost_regex-mt boost_system-mt boost_thread-mt c fftw3f WANTLIB += fftw3f_threads gmp gmpxx gsl gslcblas gsm iconv jack -WANTLIB += log4cpp m orc-0.4 portaudio qwt-qt5 zmq +WANTLIB += log4cpp m orc-0.4 portaudio qwt zmq MASTER_SITES = https://github.com/gnuradio/gnuradio/releases/download/v$V/ @@ -92,7 +93,7 @@ LIB_DEPENDS = audio/jack \ devel/sdl \ math/fftw3,float \ net/zeromq \ - x11/qwt,qt5 + x11/qwt CONFIGURE_ARGS =-DENABLE_DOXYGEN=OFF \ -DENABLE_GR_UHD=OFF \ diff --git a/geo/qgis/Makefile b/geo/qgis/Makefile index a419dad45e3..9ac6e6c4d43 100644 --- a/geo/qgis/Makefile +++ b/geo/qgis/Makefile @@ -11,6 +11,7 @@ DISTNAME =qgis-3.16.0 EXTRACT_SUFX = .tar.bz2 CATEGORIES = geo x11 DEBUG_PACKAGES =${BUILD_PACKAGES} +REVISION = 0 SHARED_LIBS = qgis_core 45.0 \ qgis_app31.0 \ @@ -70,7 +71,7 @@ LIB_DEPENDS = ${MODPY_LIB_DEPENDS} \ www/fcgi \ x11/qt5/qtwebkit \ x11/qt5/qt3d \ - qwt-*-qt5:x11/qwt,qt5 \ + x11/qwt \ geo/gdal \ geo/mdal>=0.5 \ geo/geos \ @@ -84,7 +85,7 @@ WANTLIB += ${COMPILER_LIBCXX} Qt5Concurrent Qt5Core Qt5Gui Qt5Network WANTLIB += Qt5Positioning Qt5PrintSupport Qt5Sql Qt5Svg WANTLIB += Qt5Test Qt5WebKit Qt5WebKitWidgets Qt5Widgets Qt5Xml WANTLIB += c exiv2 expat fcgi gdal geos_c gsl gslcblas m mdal pq proj ${MODPY_WANTLIB} -WANTLIB += qca-qt5 qscintilla2_qt5 qt5keychain qwt-qt5 spatialindex +WANTLIB += qca-qt5 qscintilla2_qt5 qt5keychain qwt spatialindex WANTLIB += spatialite sqlite3 util zip hdf5 xml2 z GL WANTLIB += Qt53DCore Qt53DExtras Qt53DInput Qt53DLogic WANTLIB += Qt53DRender Qt5Gamepad protobuf-lite diff --git a/x11/qwt/Makefile b/x11/qwt/Makefile index 0c9f1c089c2..a9a5d5b971a 100644 --- a/x11/qwt/Makefile +++ b/x11/qwt/Makefile @@ -1,64 +1,37 @@ # $OpenBSD: Makefile,v 1.29 2019/07/12 20:51:20 sthen Exp $ -COMMENT-main = Qt Widgets for Technical Applications -COMMENT-common = common files for the qwt packages +COMMENT= Qt widgets for technical applications -VERSION = 6.1.3 -DISTNAME = qwt-${VERSION} -SHARED_LIBS = qwt${QTLIBSUFFIX} 7.0 -PKGNAME-main = qwt-${VERSION} -FULLPKGNAME-common = qwt-common-${VERSION} -FULLPKGPATH-common = x11/qwt,-common -REVISION = 2 +VERSION = 6.1.5 +DISTNAME = qwt-${VERSION} -CATEGORIES = x11 -EXTRACT_SUFX = .tar.bz2 +SHARED_LIBS = qwt${QTLIBSUFFIX} 7.0 -HOMEPAGE = http://qwt.sourceforge.net/ +CATEGORIES = x11 -MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=qwt/} +HOMEPAGE = http://qwt.sourceforge.net/ + +MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=qwt/} +EXTRACT_SUFX = .tar.bz2 # Qwt License, Version 1.0 # http://qwt.sourceforge.net/qwtlicense.html PERMIT_PACKAGE = Yes -MODULES = devel/qmake +WANTLIB += Qt5Gui Qt5OpenGL Qt5PrintSupport Qt5Svg Qt5Widgets +WANTLIB +
Re: Unmaze Qt4 from x11/qwt
On Sat, Oct 31, 2020 at 06:39:49PM +0100, Rafael Sadowski wrote: > On Fri Mar 13, 2020 at 09:58:29PM +0100, Rafael Sadowski wrote: > > Is anyone willing to make x11/qwt qt5 only without -common etc.? The > > difficult part is to set the right @pkgpath/@conflict.. foo and thus > > enable a pkg_add update. > > > > No more customers available for the Qt4 (main) parts, only Qt5. > > > > I'm looking forward to test diff. > > > > Rafael Sadowski > > > > Here is my final version. I've adjusted gnuradio and qgis. > The pkg_add upgrade process looks ok, right? reads good to me, thanks for this cleanup !
games/dMagnetic 0.25 -> 0.26 (Now it can load Amstrad CPC binaries)
Hello. My project dMagnetic saw release 0.26. With this one, it is possible to play the original Amstrad CPC releases of "The Pawn", "The Guild of Thieves", "Jinxter" and "Corruption". I took the liberty of updating the port for OpenBSD. Please find the patch attached to this Email. Hopefully, it meets your standards. Thomas Dettbarn --- Makefile.orig 2020-10-31 20:17:32.019290208 +0100 +++ Makefile 2020-10-31 20:17:32.023237365 +0100 @@ -1,6 +1,6 @@ # $OpenBSD: Makefile,v 1.13 2020/07/26 16:47:51 sthen Exp $ -V = 0.25 +V = 0.26 COMMENT = interpreter for Magnetic Scrolls games DISTNAME = dMagnetic_${V} PKGNAME = dmagnetic-${V} --- distinfo.orig 2020-10-31 20:17:32.023237365 +0100 +++ distinfo 2020-10-31 20:17:32.027184522 +0100 @@ -1,2 +1,2 @@ -SHA256 (dMagnetic_0.25.tar.bz2) = XL4q7n6IcGKOrq8v4/xVDzFzb+YXiXZIp3KDvmo4Hm0= -SIZE (dMagnetic_0.25.tar.bz2) = 68283 +SHA256 (dMagnetic_0.26.tar.bz2) = gemINv/jzJScMMs46O8vyK5+gOQ/8DPBfW8Goh9EtfA= +SIZE (dMagnetic_0.26.tar.bz2) = 72758
Re: assembler error on trying to port OpenBLAS
On 10/29/20 8:25 PM, Aisha Tammy wrote: Hi, I'm trying to port OpenBLAS to the tree and am currently getting some weird assembler errors (port makefile is attached at end math/openblas) ../kernel/x86_64/saxpy_microk_sandy-2.c: Assembler messages: ../kernel/x86_64/saxpy_microk_sandy-2.c:37: Error: no such instruction: `vbroadcastss (%rcx),%ymm0' ../kernel/x86_64/saxpy_microk_sandy-2.c:38: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8' ../kernel/x86_64/saxpy_microk_sandy-2.c:39: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9' ../kernel/x86_64/saxpy_microk_sandy-2.c:40: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10' ../kernel/x86_64/saxpy_microk_sandy-2.c:41: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11' ../kernel/x86_64/saxpy_microk_sandy-2.c:42: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:43: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:44: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:45: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:51: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:52: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12' ../kernel/x86_64/saxpy_microk_sandy-2.c:53: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:54: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13' ../kernel/x86_64/saxpy_microk_sandy-2.c:55: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:56: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14' ../kernel/x86_64/saxpy_microk_sandy-2.c:57: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:58: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15' ../kernel/x86_64/saxpy_microk_sandy-2.c:59: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8' ../kernel/x86_64/saxpy_microk_sandy-2.c:60: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9' ../kernel/x86_64/saxpy_microk_sandy-2.c:61: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10' ../kernel/x86_64/saxpy_microk_sandy-2.c:62: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11' ../kernel/x86_64/saxpy_microk_sandy-2.c:63: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:64: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:65: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:66: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:67: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:68: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:69: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:70: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:75: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:76: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:77: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:78: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:79: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12' ../kernel/x86_64/saxpy_microk_sandy-2.c:80: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13' ../kernel/x86_64/saxpy_microk_sandy-2.c:81: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14' ../kernel/x86_64/saxpy_microk_sandy-2.c:82: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15' ../kernel/x86_64/saxpy_microk_sandy-2.c:83: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:84: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:85: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:86: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:87: Error: no such instruction: `vzeroupper ' Presumably this is happening due to the assembler being used is the one from base as we don't build the ports egcc with gas for anything except aarch64 and arm. I'm kind of stumped here as it seems like using gfortran sets the compiler to egcc (compiling the above file with cc works). Is it possible to mix gfortran with base-clang C compiler? Another (possible) solution would be to build egcc all archs with th
sparc64 bulk build report
Bulk build on sparc64-0.ports.openbsd.org Started : Thu Oct 29 22:35:16 MDT 2020 Finished: Sat Oct 31 15:18:25 MDT 2020 Duration: 1 Days 16 hours 43 minutes Built using OpenBSD 6.8-current (GENERIC.MP) #539: Thu Oct 29 06:21:39 MDT 2020 Built 8089 packages Number of packages built each day: Oct 29: 1588 Oct 30: 6004 Oct 31: 497 Critical path missing pkgs: http://build-failures.rhaalovely.net/sparc64/2020-10-29/summary.log Build failures: 9 http://build-failures.rhaalovely.net/sparc64/2020-10-29/devel/libvmime.log http://build-failures.rhaalovely.net/sparc64/2020-10-29/devel/spidermonkey78.log http://build-failures.rhaalovely.net/sparc64/2020-10-29/math/py-scikit-learn,python3.log http://build-failures.rhaalovely.net/sparc64/2020-10-29/sysutils/dwdiff.log http://build-failures.rhaalovely.net/sparc64/2020-10-29/sysutils/libvirt.log http://build-failures.rhaalovely.net/sparc64/2020-10-29/textproc/libical.log http://build-failures.rhaalovely.net/sparc64/2020-10-29/textproc/py-ICU.log http://build-failures.rhaalovely.net/sparc64/2020-10-29/www/purritobin.log http://build-failures.rhaalovely.net/sparc64/2020-10-29/x11/picom.log Recurrent failures: failures/devel/spidermonkey78.log failures/sysutils/libvirt.log failures/www/purritobin.log failures/x11/picom.log New failures: +failures/devel/libvmime.log +failures/math/py-scikit-learn,python3.log +failures/sysutils/dwdiff.log +failures/textproc/libical.log +failures/textproc/py-ICU.log Resolved failures: -failures/security/suricata.log Packages newly built: +databases/py-whisper,python3 +devel/arduino-esp32 +devel/p5-IO-Interactive +devel/xtensa-esp32-elf/binutils +devel/xtensa-esp32-elf/gcc +devel/xtensa-esp32-elf/gcc-bootstrap +devel/xtensa-esp32-elf/gdb +devel/xtensa-esp32-elf/newlib +lang/janet +net/py-rrdtool,python3 +security/suricata +sysutils/py-threadpoolctl,python3 Packages not built this time: -devel/libvmime -games/spacehulk -graphics/k3dsurf -math/py-scikit-learn,python3 -net/rrdtool,-python -sysutils/dwdiff -sysutils/py-croniter -sysutils/py-croniter,python3 -textproc/libical -textproc/libical,-glib -textproc/libical,-main -textproc/py-ICU -textproc/py-ICU,python3 -textproc/py-natsort
Re: ghc 8.10.2 won't build haddock on i386
On Thu, Oct 29, 2020 at 10:23 PM Greg Steuck wrote: > I believe I implemented this in > https://github.com/blackgnezdo/ports/commit/3707bd2f19dd4479f4a215aadf33afed36a55f23 > Not entirely sure if it is correct as I only ran it through some > incremetal experiments and complete builds > are still underway. > This stuff is nearly impossible to get right the first time. Now I tested it completely on both amd64 and i386. https://github.com/blackgnezdo/ports/commit/797790009486f9201558d14540bf678d60a52117 The evolving tree is here: https://github.com/blackgnezdo/ports/commits/pfrag-ghc It is up to date with the most recent cabal 3.4-rc5. A minor nit in xmobar port has also been resolved by the upstream release. Still yearning for feedback :) Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
Re: Update to py-requests-2.24.0
On Wed, Oct 28, 2020 at 09:36:16PM -0400, Daniel Jakots wrote: > On Wed, 14 Oct 2020 22:32:56 -0400, Daniel Jakots wrote: > > On Wed, 14 Oct 2020 13:06:33 +0200, Antoine Jacoutot > > wrote: > > > > Here's a diff for py-requests. I had trouble with 2.23's test > > > > suite. I found a solution for 2.24 from > > > > https://github.com/pytest-dev/pytest/issues/2042#issuecomment-429289164 > > > > There are still some failures. > > > Looks fine to me. > > > Do these failures appear in the previous version? > > No, tests in the current version are better. There are some > > failures because > > SSLError: HTTPSConnectionPool(host='127.0.0.1', port=37564): Max > > retries exceeded with url: > > /redirect-to?url=http%3A%2F%2F127.0.0.1%3A12892%2Fget (Caused by > > SSLError(CertificateError("hostname '127.0.0.1' doesn't match either > > of 'localhost', '127.0.0.1'",),)) > > which is weird. I don't remember them > > from last time I updated the port, so maybe a TDEP changed in the > > meantime? > > Anyway, I've been using the update and it works fine for me (that > > said, my requests use is quite small). > ping py-requests has a lot of consumers. Did you run through regression tests on a number of these to make sure this doesn't break them? --Kurt
Re: UPDATE: Boost 1.70
On Fri, 30 Oct 2020, Stuart Henderson wrote: > comms/sigrok/pulseview > > In file included from pulseview_autogen/mocs_compilation.cpp:6: > In file included from pulseview_autogen/4KQHGSF5UX/moc_analogsegment.cpp:10: > In file included from > pulseview_autogen/4KQHGSF5UX/../../../pulseview-0.4.1/pv/data/analogsegment.hpp:23: > In file included from > pulseview_autogen/4KQHGSF5UX/../../../pulseview-0.4.1/pv/data/segment.hpp:24: > In file included from /pobj/pulseview-0.4.1/pulseview-0.4.1/pv/util.hpp:28: > /usr/local/include/boost/multiprecision/cpp_dec_float.hpp:613:12: error: > implicit instantiation of undefined template 'boost::serialization::nvp' > > How about this? Does someone want to check it works with the in-tree version of boost as well? diff -Nur pulseview/Makefile pulseview.new/Makefile --- pulseview/Makefile Fri Mar 8 15:00:40 2019 +++ pulseview.new/Makefile Sat Oct 31 20:58:58 2020 @@ -1,8 +1,7 @@ # $OpenBSD: Makefile,v 1.4 2019/03/08 20:00:40 cwen Exp $ COMMENT = command-line frontend for sigrok logic analyzer -REVISION = 1 - +REVISION = 2 SIGROK_PROJECT = pulseview SIGROK_VERSION = 0.4.1 diff -Nur pulseview/patches/patch-pv_util_hpp pulseview.new/patches/patch-pv_util_hpp --- pulseview/patches/patch-pv_util_hpp Wed Dec 31 19:00:00 1969 +++ pulseview.new/patches/patch-pv_util_hpp Sat Oct 31 21:11:35 2020 @@ -0,0 +1,15 @@ +$OpenBSD$ + +backport commit 136b891 to work around boost + clang10 issue + +Index: pv/util.hpp +--- pv/util.hpp.orig pv/util.hpp +@@ -25,6 +25,7 @@ + #include + + #ifndef Q_MOC_RUN ++#include + #include + #endif +
aarch64 bulk build report
bulk build on arm64.ports.openbsd.org started on Thu Oct 29 04:54:03 MDT 2020 finished at Sat Oct 31 20:02:29 MDT 2020 lasted 2D15h08m done with kern.version=OpenBSD 6.8-current (GENERIC.MP) #873: Thu Oct 29 01:43:00 MDT 2020 built packages:10867 Oct 29:4196 Oct 30:1292 Oct 31:5378 critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2020-10-29/summary.log build failures: 17 http://build-failures.rhaalovely.net/aarch64/2020-10-29/converters/wv2.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/devel/sqlc.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/editors/calligra.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/editors/xwpe.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/emulators/vice.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/games/shockolate.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/lang/pfe.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/security/age.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/sysutils/docker-cli.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/sysutils/facette.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/sysutils/nomad.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/sysutils/rclone.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/sysutils/telegraf.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/sysutils/terragrunt.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/www/chromium.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/x11/e17/e.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/x11/qt5/qtwebkit.log recurrent failures failures/emulators/vice.log failures/games/shockolate.log failures/lang/pfe.log failures/security/age.log failures/sysutils/docker-cli.log failures/sysutils/facette.log failures/sysutils/telegraf.log failures/sysutils/terragrunt.log failures/www/chromium.log failures/x11/qt5/qtwebkit.log new failures +++ ls-failures Sat Oct 31 20:02:43 2020 +failures/x11/e17/e.log resolved failures --- ../old/aarch64/last//ls-failuresWed Oct 28 05:31:34 2020 -failures/net/kdsoap.log -failures/x11/e17/elementary.log
Re: UPDATE: Boost 1.70
On Sat, Oct 31, 2020 at 09:19:41PM -0400, Daniel Dickman wrote: > > > On Fri, 30 Oct 2020, Stuart Henderson wrote: > > > comms/sigrok/pulseview > > > > In file included from pulseview_autogen/mocs_compilation.cpp:6: > > In file included from pulseview_autogen/4KQHGSF5UX/moc_analogsegment.cpp:10: > > In file included from > > pulseview_autogen/4KQHGSF5UX/../../../pulseview-0.4.1/pv/data/analogsegment.hpp:23: > > In file included from > > pulseview_autogen/4KQHGSF5UX/../../../pulseview-0.4.1/pv/data/segment.hpp:24: > > In file included from /pobj/pulseview-0.4.1/pulseview-0.4.1/pv/util.hpp:28: > > /usr/local/include/boost/multiprecision/cpp_dec_float.hpp:613:12: error: > > implicit instantiation of undefined template > > 'boost::serialization::nvp' > > > > > > How about this? Does someone want to check it works with the in-tree > version of boost as well? > > diff -Nur pulseview/Makefile pulseview.new/Makefile > --- pulseview/MakefileFri Mar 8 15:00:40 2019 > +++ pulseview.new/MakefileSat Oct 31 20:58:58 2020 > @@ -1,8 +1,7 @@ > # $OpenBSD: Makefile,v 1.4 2019/03/08 20:00:40 cwen Exp $ > > COMMENT =command-line frontend for sigrok logic analyzer > -REVISION = 1 > - > +REVISION = 2 > SIGROK_PROJECT = pulseview > SIGROK_VERSION = 0.4.1 > > diff -Nur pulseview/patches/patch-pv_util_hpp > pulseview.new/patches/patch-pv_util_hpp > --- pulseview/patches/patch-pv_util_hpp Wed Dec 31 19:00:00 1969 > +++ pulseview.new/patches/patch-pv_util_hpp Sat Oct 31 21:11:35 2020 > @@ -0,0 +1,15 @@ > +$OpenBSD$ > + > +backport commit 136b891 to work around boost + clang10 issue > + > +Index: pv/util.hpp > +--- pv/util.hpp.orig > pv/util.hpp > +@@ -25,6 +25,7 @@ > + #include > + > + #ifndef Q_MOC_RUN > ++#include > + #include > + #endif > + I had sent the following diff from upstream to the MAINTAINER. The diff you have, from the git hash, is based on what I have. I built with both versions. Index: Makefile === RCS file: /cvs/ports/comms/sigrok/pulseview/Makefile,v retrieving revision 1.4 diff -u -p -u -p -r1.4 Makefile --- Makefile8 Mar 2019 20:00:40 - 1.4 +++ Makefile30 Oct 2020 19:52:38 - @@ -1,7 +1,7 @@ # $OpenBSD: Makefile,v 1.4 2019/03/08 20:00:40 cwen Exp $ COMMENT = command-line frontend for sigrok logic analyzer -REVISION = 1 +REVISION = 2 SIGROK_PROJECT = pulseview SIGROK_VERSION = 0.4.1 Index: patches/patch-pv_util_hpp === RCS file: patches/patch-pv_util_hpp diff -N patches/patch-pv_util_hpp --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-pv_util_hpp 30 Oct 2020 19:52:38 - @@ -0,0 +1,17 @@ +$OpenBSD$ + +pv/util.hpp: Workaround for a Boost::serialization / clang++-10 issue. + +Index: pv/util.hpp +--- pv/util.hpp.orig pv/util.hpp +@@ -25,6 +25,9 @@ + #include + + #ifndef Q_MOC_RUN ++// Workaround for https://github.com/boostorg/serialization/issues/186 ++#include ++ + #include + #endif +
Re: assembler error on trying to port OpenBLAS
On 10/31/2020 12:57 PM, Aisha Tammy wrote: On 10/29/20 8:25 PM, Aisha Tammy wrote: Hi, I'm trying to port OpenBLAS to the tree and am currently getting some weird assembler errors (port makefile is attached at end math/openblas) ../kernel/x86_64/saxpy_microk_sandy-2.c: Assembler messages: ../kernel/x86_64/saxpy_microk_sandy-2.c:37: Error: no such instruction: `vbroadcastss (%rcx),%ymm0' ../kernel/x86_64/saxpy_microk_sandy-2.c:38: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8' ../kernel/x86_64/saxpy_microk_sandy-2.c:39: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9' ../kernel/x86_64/saxpy_microk_sandy-2.c:40: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10' ../kernel/x86_64/saxpy_microk_sandy-2.c:41: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11' ../kernel/x86_64/saxpy_microk_sandy-2.c:42: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:43: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:44: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:45: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:51: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:52: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12' ../kernel/x86_64/saxpy_microk_sandy-2.c:53: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:54: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13' ../kernel/x86_64/saxpy_microk_sandy-2.c:55: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:56: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14' ../kernel/x86_64/saxpy_microk_sandy-2.c:57: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:58: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15' ../kernel/x86_64/saxpy_microk_sandy-2.c:59: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8' ../kernel/x86_64/saxpy_microk_sandy-2.c:60: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9' ../kernel/x86_64/saxpy_microk_sandy-2.c:61: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10' ../kernel/x86_64/saxpy_microk_sandy-2.c:62: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11' ../kernel/x86_64/saxpy_microk_sandy-2.c:63: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:64: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:65: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:66: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:67: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:68: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:69: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:70: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:75: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:76: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:77: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:78: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:79: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12' ../kernel/x86_64/saxpy_microk_sandy-2.c:80: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13' ../kernel/x86_64/saxpy_microk_sandy-2.c:81: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14' ../kernel/x86_64/saxpy_microk_sandy-2.c:82: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15' ../kernel/x86_64/saxpy_microk_sandy-2.c:83: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:84: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:85: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:86: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:87: Error: no such instruction: `vzeroupper ' Presumably this is happening due to the assembler being used is the one from base as we don't build the ports egcc with gas for anything except aarch64 and arm. I'm kind of stumped here as it seems like using gfortran sets the compiler to egcc (compiling the above file with cc works). Is it possible to mix gfortran with base-clang C compiler? Another (possible) so