Yet another variable to permit skipping of runtime dependency checks
for a list of files, specifying their absolute path in the $DESTDIR,
allows us to handle known bad detections due to e.g. binaries or
shared libraries not meant to be run or loaded in the host.
This will be used to fix the android-studio template to skip
a number of files which would create a bogus dependency on libc.so.
Signed-off-by: Jürgen Buchmüller <pullmoll@t-online.de>
In order to make builds more reproducible SOURCE_DATE_EPOCH was set to
the time of the last commit that touched the template. Since trying to
reproduce a build from a different revision is futile (the most obvious
reason is that the source-revisions property includes the HEAD commit
hash) and looking up the commit in question can take several seconds,
stop wasting time an just use HEAD.
Closes: #12314 [via git-merge-pr]
This still isn't perfect. When the common/xbps-src/shutils/chroot.sh
function chroot_init() is called, the value for $XBPS_FFLAGS, which is
defined in common/build-profiles/bootstrap.sh, is empty.
Put the immediate value into the generated /etc/xbps/xbps-src.conf
file until someone finds out where passing the value of $XBPS_FFLAGS
throughout the scripts is missing.
Add another stage 'check' between 'build' and 'install'. It is be enabled using the
variable XBPS_CHECK_PKGS=yes and disabled if unset, set to "0" or "no" in your
local etc/conf.
A new xbps-src option `-q` for `quick` will disable XBPS_CHECK_PKGS by overriding it to 0.
If enabled, `common/xbps-src/shutils/xbps-src-docheck.sh` checks for an existing
`do_check()` function in the package's template and, if it exists, calls it.
A new template variable `checkdepends` may be present and list packages required
to run the `do_check()` function. Example: `checkdepends="bc unittest-cpp"`.
- python_module build style now builds modules for python2/3 by default
- new python2_module and python3_module build styles for building
python2-only and python3-only packages respectively
- no more python_versions
- no need to define pycompile_version for Python modules anymore
(still needed for non-Python modules though)
- Python version and paths are now guessed automatically and a set of
useful variables can now be used in templates
- #!/usr/bin/python2 and #!/usr/bin/python3 are now the default shebangs
- /usr/bin/foo2 and /usr/bin/foo3 are now the default names for bin
scripts (for use with alternatives)
Thanks to @chneukirchen for finding the correct solution:
gcc sets -mno-shared by default when compiling non-PIC, and because
we are overriding the builtin specs, this internal rule set for gnu/mips
does not trigger:
gcc/config/mips/gnu-user.h:/* Default to -mno-shared for non-PIC. */
gcc/config/mips/gnu-user.h: " %{mshared|mno-shared|fpic|fPIC|fpie|fPIE:;:-mno-shared}"
So that we now use a specific specs file just for mips that sets -mshared for PIC.
This fixes building packages with hardening enabled for MIPS.
I just booted a full PIE base-system successfully on my CI20 Creator.
For now we set -fPIE again in C{,XX}FLAGS to fix the build in attr/acl/coreutils, etc.
glibc is a wonderful library. Tidy and clean. To keep it that clean
it does such useful things as sorting the CFLAGS alphabeticly.
Unfortunately this breaks command line arguments that contain parameters
such as `-include /foo/bar`. This commit works around this flaw by
removing the space and using -include/foo/bar instead.
This reverts commit c46b43df61.
lynx was complaining about missing " in the CFLAGS. apparently this is an error in the lynx
build system, not in the CFLAGS.
Note that -fPIE defines __PIC__ and __PIE__, so passing this on to
pure cpp(1)/gcc -E executions is relevant.
Found the hard way due to ccache breaking on i686 with precompiled
headers which used the non-PIC definitions in cpuid.h since header
precompilation doesn't read cc1_options.
Go 1.5 doesn't permit our use of GOBIN anymore, breaking
cross-compilation (for details, see
https://github.com/golang/go/issues/9769)
In retrospect, I'm not sure why we set GOBIN in the first place;
GOPATH/bin should suffice.
Closes#2337
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.
