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.
The `etc/virtual` file declares the default package to be built for
virtual dependencies declared as "virtual?foo" in $depends.
Before this change, the run-time dependency was added as is to the final
binary package but no pkg providing this virtual pkg was built.
With this file we declare the *default* pkg to be built.
NOTE: "virtual?foo" is only applicable to *run* time dependencies, i.e
only those declared in $depends.
- 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.
localedef is only available with glibc, so that defer locale creation
once the chroot is ready.
This fixes installing bootstrap glibc pkgs on musl hosts.
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
