Cross compiling go programs with cross-native2 fails for armv7, riscv64
and armhf unless we use CGO_ENABLED=1 in the APKBUILD (see related
aports issue).
Add --sysroot to CGO_CFLAGS, so cgo can find the includes and doesn't
fail with:
go build -buildmode=pie -modcacherw -trimpath -buildvcs=false -ldflags "-s -w -X main.Version=2.6.1" -o mkinitfs ./cmd/mkinitfs
# runtime/cgo
_cgo_export.c:3:10: fatal error: stdlib.h: No such file or directory
Add it to LDFLAGS too for linking against libraries from the sysroot.
Related: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15809
Related: https://stackoverflow.com/a/38835938
Fixes a bug where checkdepends are not being installed, and packages
that run tests that depend on something in checkdepends fail because
it's missing. For example, the `plasma-workspace` forked pkg in pmaports
tells abuild to run `xwfb-run` in `check()`, this binary comes from
`xwayland-run`, which is listed in the `checkdepends`. However this
isn't being installed and so `pmb build` ultimately fails to build the
package.
Set things up so that we can run abuild on the native chroot and use
it's cross compilation features rather than running it and the build
system through QEMU. This massively speeds up building when it works.
cross-native used to be quite limited in functionality and didn't
integrate into abuild itself, this commit fixes that.
Packages can opt-in to this by adding pmb:cross-native2 to their options
and configuring makedepends_host and makedepends_build.
This also speeds up building packages like postmarketos-initramfs since
it entirely avoids running commands through QEMU (usually abuild itself
would be run through QEMU).
Lastly, we preserve the old pmb:cross-kernel options, this can be used to
enable the old cross compiler behaviour which is used for cross
compiling kernels in pmaports. This allows them to keep being supporting
while we adapt them to the new cross-native2.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
I tried my best to get the right author based on git commit history, but
in the case of code being moved from one file to make another I might
have gotten something wrong.
the kernel has pending patches in -next which adjust the generated
Makefile in the output directory to include the source tree makefile
with an absolute path, this breaks envkernel which relies on it being a
relative path.
Fix this by mounting our own Makefile instead using the relative path.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Otherwise abuild will try and fail to create /dev/null
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
[ci:skip-build]: already built successfully in CI
recent changes to the kernels build infra in -next seem to have exposed
some issues with "pmbootstrap build --envkernel", specifically in the
case where the APKBUILD doesn't build out-of-tree.
We used to rely on the fact that the kernel output directory contains a
Makefile which points to the source directory, however this Makefile
now(?) contains an absolute path on the host, which won't match what's
in the chroot.
As a result, it's now necessary to build with the same output directory
as the APKBUILD.
We probably need some smarter code here... and/or more consistent
APKBUILDs.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Replace aports -> pmaports in these messages.
$ pmbootstrap build systemd
[17:37:02] NOTE: The package 'systemd' exists in extra-repos/systemd, but systemd is currently disabled
[17:37:02] ERROR: Could not find package 'systemd' in pmaports
There was an oversight when this API was originally created and it
implicitly assumed that the pmaports repository was always named
"pmaports". This unfortunately broke some peoples workflows.
Introduce a new "pkgrepo_name()" function and adjust the codebase to use
it, as well as adjusting pkgrepo internally to special case the
"pmaports" repo so that it's always named pmaports no matter what the
directory itself is named.
This is probably more complexity than we should be dealing with here, we
should probably create a new type to encode this behaviour.
Fixes: #2412
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
At some point, this function was updated to use the Arch type instead of
plain strings, but the return type was left omitted and the docstring
outdated.
Some packages in aports have their own subpackages in their
dependencies, for some reason. This causes our resolver to assume there
is a cyclical dependency.
Adjust the resolver to safely ignore these dependencies, since they'll
be built as a part of the package that depends on them.
For example, modemmanager depends on libmm-glib which is a subpackage of
modemmanager. Currently to build modemmanager in pmaports it would be
necessary to manually modify the APKBUILD after copying it from aports.
This change avoids that.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
It may be desirable to test older versions of packages, allow them to be
built when --force is specified and print a warning that they won't be
installed automatically.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
I don't think there's any case where the number of jobs would have to be
a string. It's also being assigned an integer elsewhere the code (in
ask_for_additional_options() inside of init.py), so an integer seems
like what we actually want. Also fix type errors resulting of this.
Here's the problem: Imagine a queue with 2 packages in it, the 1st
package uses crossdirect and the second uses cross-native. When building
the 1st package, pmb will configure the native chroot for crossdirect
as expected. When it gets to the 2nd package, the chroot env/config
might not be appropriate for actually doing a native cross compile.
This re-inits the cross compiler stuff if the cross compile method
changes while processing the queue.
Another approach that might solve this problem is to not re-use chroots
when building packages... I didn't think this was a good way to go
because it would greatly increase runtime (having to recreate chroots
multiple times)
When a dependency cannot be found in source or binary packages of the
selected architecture, then don't look for binary packages in other
architectures package indexes.
This leads to a confusing error down the line when building packages for
extra_repos_systemd (and e.g. stable branches), because we don't have
binary packages for all arches that pmbootstrap supports, and so it
tries to fetch a non-existing APKINDEX.
Instead, print a nice error about a non-existing dependency.
Adjust the dependency resolver, so it uses the main pkgnames in
dependency resolution, instead of subpackages. This fixes for example
that it couldn't find -dev packages even though the binary packages for
those existed.
> systemd: missing dependency linux-pam-dev, trying to queue other packages first
> linux-pam: missing dependency systemd-dev, trying to queue other packages first
> dbus: missing dependency systemd-dev, trying to queue other packages first
Have messages like the following in "pmbootstrap log" to better
understand why resolving packages fails. The bug with -dev pkgs not
being recognized will be fixed in a follow-up patch.
> systemd: missing dependency linux-pam-dev, trying to queue other packages first
> linux-pam: missing dependency systemd-dev, trying to queue other packages first
> dbus: missing dependency systemd-dev, trying to queue other packages first
Print a warning when breaking cyclical dependencies, for example with
current kde-nightly branch:
> WARNING: cyclical build dependency, building kirigami with binary package of qqc2-desktop-style
Set "stuck = False" in the "while disarray and not stuck" loop
directly, instead of setting it in the queue_item() function that gets
called from it. This way the loop logic can be understood without
looking at queue_item().
Most of the time when building it's reasonably safe to fall back on an
older binary package for building in order to break cyclical
dependencies (e.g. dbus and systemd depend on each other at build time,
but it's safe to build both against older versions of the other).
Implement the necessary logic to break cyclical dependencies by
detecting them and checking for the existence of a binary package.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Tweaked-by: Oliver Smith <ollieparanoid@postmarketos.org>
Decide the order to build packages in by looking through the build queue
and making sure dependencies are queued before any packages that depend
on them, bailing out in the case of cyclical dependencies.
This should handle subpackages too.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
