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.
This is a second go at #18472 with (in my opinion) a better approach using
subpackages instead of build time options.
libaldmb is a separate library that isn't used by the rest of the package
and splitting it avoids a bunch of unnecessary X11 & other desktop
dependencies on `dumb`.
For the reference player I created a `dumbplay` subpackage which keeps the SDL2
dependency out of the main library package, the tiny dumbout util has minimal
dependencies and thus probably belongs in the main package.
I also updated the homepage which still pointed to the old pre-fork page.
Continuation of my work at #28422
Upstream mcpp is abandonware and is missing features newer versions of Ice
need to build. There are supposedly patches applicable to the official mcpp
that allows it to work but I couldn't see links to any (I'm guessing they live
in distros). Instead I tried packaging ZeroC's officially maintained stripped
down library only version (see previous commit e617a384).
Tests have been disabled because they take a disgustingly long time to build
and have to be hand blacklisted to the ones that don't fail on each platform.
I tested this package by building and running Murmur from the `mumble` package.
Almost all of the patches had completely bit-rotted, I salvaged a few that was
still relevant but the rest had to be thrown away. I made the changes
necessary to cross-compile to aarch64-musl but the result untested as I don't
have any exotic systems to test with (`mumble` was built for aarch64-musl
as well).
libtool will insert RPATH if $libdir not in sys_lib_dlsearch_path_spec.
libtool's configure will parse /etc/ld.so.conf for this value.
Without this change the original value is:
- glibc: /lib /usr/lib /usr/lib32 /usr/local/lib
- musl: /lib /usr/lib
Fix Manual accordingly, and also fix indentation to be compatible with
nearby items.
The two packages which set this variable set it explicitly to "no", so
it wasn't relied upon. From its description, it was recommended only for
git packages, which by default don't fit Void's packaging guidelines.
Removing to avoid anyone coming to rely on it.
