Re: x11/qt5/qtbase on arm
Hi,
On Wed, Oct 14, 2020 at 02:26:48PM +0100, Stuart Henderson wrote:
> > ===> poppler-20.09.0 depends on: qttools-*
> >
> > In print/poppler/Makefile you have
> >
> > NOT_FOR_ARCHS-qt5 = arm
> >
> > But there is no condition to this
> >
> > MODULES+= x11/qt5
> >
> > so qttools is pulled in.
>
> Diff to fix that below. kili, ok?
Yes, looks sane.
Ciao,
Kili
> Index: Makefile
> ===
> RCS file: /cvs/ports/print/poppler/Makefile,v
> retrieving revision 1.161
> diff -u -p -r1.161 Makefile
> --- Makefile 9 Sep 2020 20:16:44 - 1.161
> +++ Makefile 14 Oct 2020 13:06:19 -
> @@ -42,7 +42,9 @@ cWANTLIB= expat freetype fontconfig jpeg
>
> MODULES= devel/cmake
>
> +.if ${BUILD_PACKAGES:M-qt5}
> MODULES+=x11/qt5
> +.endif
>
> # devel/boost only as build+run dependency, poppler uses
> # header-only classes (from boost/containers/small_vector.hpp)
>
Re: x11/qt5/qtbase on arm
On Wed, Oct 14, 2020 at 10:06:34AM +0100, Stuart Henderson wrote: > What is the actual port you are trying to build, is it something where > it might be possible to remove qt5 from the chain instead of fixing > qt5 build? ===> poppler-20.09.0 depends on: qttools-* In print/poppler/Makefile you have NOT_FOR_ARCHS-qt5 = arm But there is no condition to this MODULES+= x11/qt5 so qttools is pulled in. But I'm here, lets take a look, qt is popular and it could fix a lot of packages, QtWebkit|QtWebengine could be useful in a machine with more ram... etc. > I am asking because bulk builds on armv7 already take about 40 days - it > is pretty much pointless building snapshot packages on an architecture > with that kind of latency (OpenBSD library ABI is not really stable > so you will be lucky to get packages that work with a given snapshot > unless you save snaps from before each library bump). > > Fixing things to enable qt5 will make this situation even worse. Even if > you don't care about snapshots, this would further delay packages being > available after "base release" of a new OS version. You don't have a way to blacklist ports in the bulk build system? Just for curiosity, what machine are you using to build the armv7 packages? adr.
Re: x11/qt5/qtbase on arm
On 2020/10/14 11:22, a...@sdf.org wrote:
> On Wed, Oct 14, 2020 at 10:06:34AM +0100, Stuart Henderson wrote:
> > What is the actual port you are trying to build, is it something where
> > it might be possible to remove qt5 from the chain instead of fixing
> > qt5 build?
>
> ===> poppler-20.09.0 depends on: qttools-*
>
> In print/poppler/Makefile you have
>
> NOT_FOR_ARCHS-qt5 = arm
>
> But there is no condition to this
>
> MODULES+= x11/qt5
>
> so qttools is pulled in.
Diff to fix that below. kili, ok?
Index: Makefile
===
RCS file: /cvs/ports/print/poppler/Makefile,v
retrieving revision 1.161
diff -u -p -r1.161 Makefile
--- Makefile9 Sep 2020 20:16:44 - 1.161
+++ Makefile14 Oct 2020 13:06:19 -
@@ -42,7 +42,9 @@ cWANTLIB= expat freetype fontconfig jpeg
MODULES= devel/cmake
+.if ${BUILD_PACKAGES:M-qt5}
MODULES+= x11/qt5
+.endif
# devel/boost only as build+run dependency, poppler uses
# header-only classes (from boost/containers/small_vector.hpp)
> But I'm here, lets take a look, qt is popular and it could fix a
> lot of packages, QtWebkit|QtWebengine could be useful in a machine
> with more ram... etc.
It's still pretty limited. RAM available to a single process is limited
by MAXDSIZ which is 1GB on armv7. Maybe qtwebkit can be got to work with
some effort, qtwebengine, which includes most of chromium, doesn't even
build on i386 (uses too much RAM), very unlikely to happen on OpenBSD on
32-bit arm.
> > I am asking because bulk builds on armv7 already take about 40 days - it
> > is pretty much pointless building snapshot packages on an architecture
> > with that kind of latency (OpenBSD library ABI is not really stable
> > so you will be lucky to get packages that work with a given snapshot
> > unless you save snaps from before each library bump).
> >
> > Fixing things to enable qt5 will make this situation even worse. Even if
> > you don't care about snapshots, this would further delay packages being
> > available after "base release" of a new OS version.
>
> You don't have a way to blacklist ports in the bulk build system?
No. Plus, a relatively complex port which isn't built in bulk builds is
unlikely to stay working for any length of time.
> Just for curiosity, what machine are you using to build the armv7
> packages?
A cluster of 4GB Cubox-i systems.
Contrast with arm64 which is very different. There is actual proper
server hardware available to use for builds for this; two machines do
a full bulk build in a couple of days, generating more packages than
are available on i386.
x11/qt5/qtbase on arm
Hello,
>From other ports I arrived to x11/qt5/qtbase.
The first broken dependency of qtbase is from pulseaudio:
audio/pulseaudio
sysutils/consolekit2
sysutils/polkit
devel/spidermonkey68 *
In Makefile it reads:
=
# Nothing in qtbase links to pulseaudio, but configure checks
# are recorded.
# The atspi is checked at configure time and used via D-Bus.
BUILD_DEPENDS =audio/pulseaudio \
=
This means that qt5 will not support pulse audio if it's not
installed before compilation?
If that is the case, as it is broken for now on arm, it wouldn't
be better to make a port flavor, or remove the dependency for arm
until pulseaudio is fixed?
I don't want to mess with mozilla for now, so I just removed the
pulseaudio dependency.
Now, the problem with qtbase is that clang is not implementing
some neon intrinsics on arm, e.g. vcvt_f16_f32.
I had problems in the past with neon in ports on arm, so I just
disabled all neon support:
===
--- Makefile.orig Tue Oct 13 23:24:26 2020
+++ MakefileTue Oct 13 23:24:13 2020
@@ -116,8 +116,8 @@
# Nothing in qtbase links to pulseaudio, but configure checks
# are recorded.
# The atspi is checked at configure time and used via D-Bus.
-BUILD_DEPENDS =audio/pulseaudio \
- geo/geoclue \
+#BUILD_DEPENDS = audio/pulseaudio \
+BUILD_DEPENDS =geo/geoclue \
x11/gnome/at-spi2-core
RUN_DEPENDS-main = ${RUN_DEPENDS} \
@@ -256,8 +256,19 @@
post-extract:
mkdir -p ${WRKDIST}/mkspecs/openbsd-clang
+# Some FP16 instrinsics aren't available on arm.
+.if ${MACHINE_ARCH} == "arm"
+ grep -v 'load(qt_config)' ${FILESDIR}/clang-qmake.conf \
+ > ${WRKDIST}/mkspecs/openbsd-clang/qmake.conf
+ echo QMAKE_CFLAGS = -U__ARM_NEON__ -U__ARM_NEON -DPNG_ARM_NEON_OPT=0 \
+ >> ${WRKDIST}/mkspecs/openbsd-clang/qmake.conf
+ echo QMAKE_CXXFLAGS = 'QMAKE_CFLAGS' \
+ >> ${WRKDIST}/mkspecs/openbsd-clang/qmake.conf
+ echo 'load(qt_config)' >> ${WRKDIST}/mkspecs/openbsd-clang/qmake.conf
+.else
cp ${FILESDIR}/clang-qmake.conf \
${WRKDIST}/mkspecs/openbsd-clang/qmake.conf
+.endif
cp ${WRKDIST}/mkspecs/openbsd-g++/qplatformdefs.h \
${WRKDIST}/mkspecs/openbsd-clang/
===
I used an orange pi one, so I had to add 2G of swap.
The data size limit has to be increased. I used
ulimit -d 1048576
but maybe just around 600M will be sufficient.
I had to shave twice before it finished, but it compiled.
I will try in the future disabling just FP16 intrinsics with
-U__ARM_FP16_FORMAT_IEEE
Regards,
adr.
Re: x11/qt5/qtbase on arm
On 2020/10/14 07:08, a...@sdf.org wrote: > Hello, > > From other ports I arrived to x11/qt5/qtbase. What is the actual port you are trying to build, is it something where it might be possible to remove qt5 from the chain instead of fixing qt5 build? I am asking because bulk builds on armv7 already take about 40 days - it is pretty much pointless building snapshot packages on an architecture with that kind of latency (OpenBSD library ABI is not really stable so you will be lucky to get packages that work with a given snapshot unless you save snaps from before each library bump). Fixing things to enable qt5 will make this situation even worse. Even if you don't care about snapshots, this would further delay packages being available after "base release" of a new OS version.
