This pullrequest removes redundant codepaths in
xbps-src-do{build,configure,install}.sh and joins the code in the
run_step function. This causes slightly different behavior to
do_install:
Do install will chdir to wrksrc only _before_ the first step. The
current behavior is that pre_install will run without a chdir, do_ and
post_ is runned with a chdir. This is a subtle but breaking change and
may cause some templates to break at install phase.
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.
Introduce an environment variable `FCC` for fortran, just as CC,
CXX etc. are defined for the other compilers.
It is set to `${XBPS_CROSS_TRIPLET}-gfortran` when cross compiling, or
to just `gfortran` when building for the native architecture.
Use just "$FCC" now when specifying the fortran compiler in a template.
It seems that some (many?) projects rely on the environment defining
compilers, tools and flags by specific XYZ_host and XYZ_target variables.
When cross compiling, define these environment variables.
This enables e.g. qt5/qtwebengine build to succeed. Specificially ninja
relies on these variables when cross compiling.
- XBPS_TARGET_ARCH var renamed to XBPS_TARGET_MACHINE (gets rid of an extra var).
- Renamed cross profiles to match XBPS_TARGET_MACHINE.
- Added symlinks to keep compatibility with old profiles.
Some autotool files (configure.ac) expect host build flags to be
defined as BUILD_CFLAGS, BUILD_CXXFLAGS, BUILD_CPPFLAGS and
BUILD_LDFLAGS. Especially these files tend to default to
LDFLAGS for BUILD_LDFLAGS, which makes host utilities built
with these flags fail with buildpie=yes because of differing
compiler and linker options.
One example is libatasmart where this patch fixes the build.
+ 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
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.
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.
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.
