- 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.
Fixes CVE-2020-8625 and whatever else was fixed in previous releases.
Add --disable-backtrace so it can build correctly on armv[67]l-musl,
otherwise I got errors about undefined references to _Unwind_GetIP,
which could have been provided by libunwind, but just makes the build
more complicated.
make was accidentally left hardcoded to query if a test target was
available, which meant tests wouldn't be run for most of the
applications, since they were now using ninja.
This reverts commit 2163ca2d03.
Removing `export AR=gcc-ar` was apparently done based on the assumption
that the linked issue (https://github.com/mesonbuild/meson/issues/1646)
had been solved completely on meson's side.
Instead, their solution, seen in
https://github.com/void-linux/void-packages/pull/2815, had been to force
gcc-ar for linking static libraries; by exporting `AR=ar`, we were
accidentally breaking static libraries when LTO is enabled. This was
noticed by leah while we were trying to build qemu-user-static using the
normal libglib-devel package (built with meson, which for us defaults to
enabling LTO).
Unfortunately, while correct, this change wasn't enough to fix the
static glib build, which had to resort to disabling LTO.
Allows a template to define in which circumstances its do_check phase
should run, without requiring custom do_check definitions in each
template (also makes it easier to change how build styles do things
without checking as many templates).
Add to Manual and CONTRIBUTING as well.
Missing $XBPS_MASTERDIR/tmp caused ca-certificates and glibc-locales to
fail in the reconfigure step of binary-bootstrap, since a call to mktemp
(which I couldn't locate in source though) assumed /tmp in the chroot
would be present already.
This issue was reproducible reliably for me on NixOS by doing something
like:
rm -rf masterdir
./xbps-src binary-bootstrap
The workaround I found was:
mkdir -p masterdir/tmp # or alternatively ./xbps-src clean
# which also (re-)creates masterdir/tmp
./xbps-src binary-bootstrap
This workaround is now mirrored in chroot_prepare by ensuring that tmp
always exists.
Detected when cross building timg after rebuilding GraphicsMagick with
new libdir directories. Could be fixed in all offending packages, but
it's easier to fix it in one place, and arguably more correct.
zuluplay seems maintained in zulucrypt sources, as zulucrypt cmake
complains about outdated zuluplay while the actual repo has no tag.
The only consumer is zulucrypt, which now uses the bundled zuluplay now.
The cc-rs crate will try to guess the host compiler and use default
flags these are not specifically set. The default behavior is wrong in
Void cross-compilation environments. Explicitly define HOST_CC=gcc and
use innocuous HOST_CFLAGS=-O2 just to thwart the bad defaults.
Co-authored-by: Érico Rolim <erico.erc@gmail.com>
Co-authored-by: Andrew J. Hesford <ajh@sideband.org>
Closes: #28416.
This allows templates to override do_build and not have to create the
build subdirectory used as TMPDIR in do_install; failure to create this
directory will cause pip to use (and pollute) /tmp in the masterdir.
This saves us one sed execution per file in the destdir, resulting
in a major speedup.
Grep will only consider text files and only look at the first line.
The libdir changes to use /usr/lib{32,64} instead of /usr/lib broke
cross builds for some packages that use gir, due to issues with copying
over symlinks. Since we haven't managed to track down the root cause for
the installation path, a symlink is a clean enough temporary fix. This
follows the style of the 00-libdir hooks.
Since pre-install runs for the main package and then each subpackage, it
should use PKGDESTDIR (not DESTDIR), which also enables a subpackage
that installs files during pkg_install to work cleanly.
As far as I can see, the previous hook was quite flawed. Since it was a
pre-install hook, the check for a directory would happen *before*
package installation (so nothing would happen). The only reason it did
anything was because it also ran as a step before a subpackage's
pkg_install (most GIR packages have a -devel subpackage), but used
DESTDIR instead of PKGDESTDIR, so it checked and affected the contents
of the main package. Then when the subpackage's pkg_install ran, the
files would have already been copied to the correct folders.
Closes#27437
Due to constant change in vala, some projects includes some old and
pre-generated vapi in their source tree and uses that version
instead of system one.
Pass system vapidir after real arguments in order to prefer its bundled
vapi.
Changed by q66:
we're now using an upstream snapshot from alpine; this should
allow us to get an assortment of regression fixes without having
to patch them in
also libssp fixes for musl, and typo fixes for libstdc++-devel
pkg function
also drop gccgo on 32-bit powerpc
Co-authored-by: q66 <daniel@octaforge.org>
Currently /etc/localtime is copied from the host to the chroot. Some
software expects /etc/localtime to be a symbolic link it can read to
determine the name of the time zone, so set up the expected link
structure.
xbps-src always ignore self deps in depends and in hostmakedepends
when not cross compiling. The old behaviour did only check for cross.
This now also ignores them in makedepends, but they are either way
disallowed in there, and returning an error would be correct, but
./xbps-src show-* is and never was suitable for linting, so ignore for now.
* $XBPS_CROSS_TRIPLET-pkg-config is our wrapper not a real executable
* In a build that have both freetype-config and pkg-config,
$XBPS_CROSS_BASE will be prepended twice with current system,
let's fix it.
this introduces a new build-style void-cross, which can be used
to write system crosstoolchain templates; this is to reduce the
amount of maintenance, resolve existing problems with the cross
toolchain templates and remove repeated code
this makes sure we don't have to worry about packages installing
stuff in lib32/lib64, it will be automagically symlinked
if something is still left over for whatever reason, or if the
opposite wordsize directory exists, that will be caught by pkglint
Also remove a few more private libraries that can be built in.
Co-authored-by: andry-dev <andry-dev@users.noreply.github.com>
Co-authored-by: Andrew J. Hesford <ajh@sideband.org>
Closes: #27300 [via git-merge-pr]
for now, these profiles set -mcpu to power8 and -mtune to power9
to match our ppc64le profiles, since there isn't really any native
harwdare to run these on (at least yet), and any packages will be
experimental for now anyway
As discussing in [1], on template with "subpackages" as multilines will
report false positive on some packages will never be built.
There're multiple problems here:
- expanded "subpackages" will have an empty line if it has a newline
inside template
- "sed" expression couldn't work with multilines "subpackages"
Let's not quote "$subpkgs" and "$subpackages" in "printf" to let the
shell do expansion and trim the empty lines for us. And rewrite the
"sed" expression to work with multilines "subpackages"
[1]: https://github.com/void-linux/void-packages/pull/26939#issuecomment-739098547
The file was created in chroot_prepare(), but the configuration
directory was being cleaned in chroot_sync_repodata(). This commit moves
the configuration to after the directories are created.
Fixes#25534
Outside of chroot, we calcucate XBPS_ALT_REPOSITORY only to throw it
away and calculate it again inside chroot. Normally, this is not problem
except when we're working with a Git's worktree, in which case, we don't
have the access to original gitdir inside chroot.
Let's bring that value from outside of chroot into it.
we don't need to specify -mcpu where compiler default is used,
preserve mtune though; do not -mno-altivec on ppc since altivec
is not default in the first place and doing this will just
break random things that explicitly enable altivec for runtime
checked code; do not use -maltivec on either ppc64le or ppc64
since it's implied by their -mcpu's (power8 for ppc64le which
is implicit, and 970 for ppc64 which is explicit)
also remove -mlong-double-64 for musl targets as that's compiler
default and it's not necessary to pass it; also remove -mabi=elfv2
for both ppc64le and ppc64 since it's implied default
