As of it's now, package built with build-helper/qmake natively won't
pick our CFLAGS CXXFLAGS and LDFLAGS. The result could be seen in no
debug symbol in djview.
Furthermore, cross build won't pick our hardening flags.
Let's force qmake pick our flags by using the same method as
build-style/qmake.
- CMAKE_BUILD_TYPE=Release will force -O3 instead of respecting our
CFLAGS and CXXFLAGS
- Theoretically, we could patch cmake to always use -O2 instead,
however, patching will break users' expectation when compiling their
our code.
- RelWithDebInfo could be another option if it's acceptable to always
have debug symbol available.
- However, some projects ignore all CFLAGS and CXXFLAGS;
- Some other projects relies on CMAKE_BUILD_TYPE=Release to install to
correct location and/or disable coverage.
- To get away with -O3, we need patching either ways, let's go with
CMAKE_BUILD_TYPE=None, and patch all problematic softwares.
- Installing gumbo-parser-devel didn't provide .so files,
because they are in the base package, so packages depending on
this library used the static one instead.
- add libgumbo to shlibs
- fix checks
- remove starting an article
Move unrelated libraries to gettext package, since they are only used by
it and by gtranslator, which will for the most part be installed
alongside gtranslator already.
The main purpose with this PR is to stop shipping unversioned libintl.so
in gettext-libs. What happens in this case is that packages built
natively for musl with localization support will have gettext in
hostmakedepends, which will lead to gettext-libs being in the host, and,
consequently, /usr/lib/libintl.so being available.
Due to CMake's FindIntl being bad, CMake projects will assume they
should use libintl.so instead of the gettext support from libc, and link
against it unnecessarily (and sometimes innefectively: CMake points the
compiler at /usr/include/libintl.h instead of our
/usr/include/gettext/libintl.h, which means the musl header will be used
instead, and unless the main executable is linked against libintl, the
library's functions won't even be used). Leaving only the essential
libraries in gettext-libs (versioned libintl.so files) and guaranteeing
gettext doesn't pull in the unversioned one means many packages won't
depend on libintl unnecessarily any more. As a matter of fact, this is a
case where our cross builds were more "correct" than native ones, since
libintl.so in the host won't be found for the target.
Furthermore, some packages require autopoint(1) in order to run
autoreconf; to avoid depending on gettext-devel for it, and ending up
linking in libintl into the final binary, we split it into the
gettext-devel-tools subpackage as well.
Also pull in Alpine patches fixing test failures.
* List dependencies of subpackages as part of the source packages
dependencies, knowing the subpackage they are coming from does
not matter to a build scheduler as long as xbps-src requires
those to exist in the same way to main depends= have to exist.
* Resolve virtual? packages through existing means in xbps-src to
avoid duplicating and possibly diverting from xbps-src's
behaviour in tools that use dbulk-dump.
* Filter out dependencies on the template itself from sub packages,
this matches the xbps-src behaviour and there is no need to
have to duplicate logic for this into the scheduling tool.
* Error out on archs= restrictions as we do already on broken=
and nocross=, there shouldn't be the need to discover archs=
restrictions when attempting to build the package.
- makedepend on mpfr-devel: used for arbitrary precision floats,
otherwise they are limited to double precision (53 bits ~ 13 digits)
- makedepend on pari-devel: used for number theory functions
- fix one line of test output to match a change in pari
- fix a bug in invmod which resulted in a test fail (chk_xavier)
- increase stacksize in musl which is needed for tests to pass
In addition to the two new makedepends, there is a small patch that
fixes one line of test output to match a change in pari.
With this commit, all 12 tests pass in glibc and in musl.
See #28989 for the original issue.
At least KiCAD tries to find wx-config-gtk3 in the current directory,
without looking for it in PATH, so the build fails. Actually give it a
full path, like we do for the cross build case.
