+ Also update gcc-multilib to gcc-4.9.3
Trying to build `gcc-multilib` failed because `glibc-32bit`
has no separate `srcpkg/glibc-32bit/template`, but is a
result of building `glibc` for target arch `i686`.
For gcc-4.9.3 to build a patch is required that gets us rid
of strange errors when including /usr/include/bits/stdio2.h
This expects a variable argument list with package names that will be
returned to stdout topologically sorted.
$ ./xbps-src sort-dependencies libarchive-devel liblzma-devel libxbps zlib-devel bzip2-devel
bzip2
xz
zlib
libarchive
xbps
Such packages should set the `restricted' var to allow building a binary package.
Note that such packages do not allow redistribution of sources and binaries,
so that it's up to the user if (s)he wants to pkg it locally.
When building with -C and without -t (xbps-uchroot(1) with overlayfs),
make sure to remove autodeps prior to start resolving dependencies.
This is necessary for cases where a previous built pkg contains the
same build dependency required for another pkg with -C, resulting
in dependencies being detected as installed and later removed.
Thanks to @dominikh and @Gottox for info and comments.
If XBPS_CHROOT_CMD == uchroot with overlayfs (-O), the temporary masterdir
will be removed completely after synchronizing remote repositories, and
later on, when the build starts the repos are unsynchronized.
So do the sync on the real masterdir before entering the chroot.
When sourcing templates to get $checksum there are templates
calling msg_error(). This is not relevant for this function,
thus define a local dummy msg_error() to ignore these cases.
This should result in a considerable performance improvement, because the
expensive configuration phase of all dependencies is skipped.
Hopefully this does not introduce build issues :-)
This was added to make sure pkg file metadata contains a different mtime
(in seconds precision), but building multiple pkgs in less than a second
will be really strange.
Available implementations at common/chroot-style/*.sh. Each .sh
script there implements a chroot style to be able to chroot and bind
mount with multiple utilities. The current supported list:
- uunshare (uses xbps-uunshare(8))
- uchroot (uses xbps-uchroot(8))
- proot (uses proot, see http://proot.me)
The XBPS_CHROOT_CMD can be set in etc/conf to use a specific implementation,
and XBPS_CHROOT_CMD_ARGS to pass in additional arguments to the cmd.
This reverts commit d803775b3d.
This breaks all pkgs that exec make directly without ${makejobs}
(which should be built as -j1) and makes installation also parallel,
which we do not want.
We'll probably resurrect this in a certain future.
This ensures that packages with custom build functions also use our
provided MAKEFLAGS. Without this commit it was necessary to always
append the "${makejobs}" variable manually to make. For compatibility
reasons that is still possible but should probably be removed in the
future by making "makejobs" a local variable.
... otherwise deps specified by the cross-vpkg-dummy pkg aren't
taken into account. Assume that version provided by the vpkg is
good enough for building.
That means that version comparators are not supported anymore in
hostmakedepends and makedepends.
This will ensure that a pkg is always built with the same build dependencies
everywhere, if the srcpkgs tree is uptodate.
The build.sh script is now responsible to handle all the logic to build
a source package and its subpackages, as well as all its required
build dependencies. Thanks to this and subshells, dependencies are now
built into its own child process, creating a process tree that can go
nested as long as your system allows forking and has enough memory :-)
This fixes some issues that have been while building pkgs that have lots
of nested dependencies.
Rather than appending to the final LDFLAGS, add it to the head,
this way packages that use LDFLAGS="-lfoo" will still work with --as-needed.
This fixes hsetroot build, at least.
Rather than setting them in the build profile, just set them in
etc/defaults.conf (overridable via etc/conf) to simplify the code.
- Also enable _FORTIFY_SOURCE=2 in CPPFLAGS.
- Also enable -z,relro in LDFLAGS.
As suggested by @chneukirchen.
This temporary masterdir contains hardlinks of files stored in a real
masterdir, and once the target has finished will be removed.
Could be useful to create fully up to date and immutable real masterdirs
that are used as base for the temporary masterdirs.