For now the GCC "c99 == gnu99" override is kept, but gnu99 is now supported as
a specific value for USE_LANGUAGES, so we may want to be specific where
required.
c11 and c17 (and the corresponding gnu11/gnu17 versions) are newly supported.
This is partly intended as a workaround to fix behaviour on NetBSD 8.x
where GCC 7 was being pulled in universally after the prior commits
here. Now it behaves as expected. There is an unaddressed issue in this
code that needs to be examined further. (This has been discussed in
more than one recent thread on teck-pkg@, including John Klos's report
of this issue.)
In any case, GCC 6 has also seen build improvements by nia@, who noted
it's safe to simply revert part of the original change set, in one of
those discussions on tech-pkg. (We can't use the hack introduced in the
prior revisions for GCC 6, though, or this same broken dependency
pattern occurs and will universally force GCC 6 instead of 7 on NetBSD
8.x.)
Tested on NetBSD 8.2_STABLE and 9.2_STABLE with various packages,
including tcsh, the original reported issue.
request a newer compiler. Stop selecting gcc6, it receives very
limited testing due to NetBSD 9 having gcc7, and probably doesn't
work due to some newer hardening checks stopping it from building.
For a long time, when cross-building, say from native=amd64 to
target=powerpc, it was necessary to:
1. cross-build a _powerpc_ package called cross-libtool-base-powerpc,
and then
2. install the powerpc package _natively_ with `pkg_add -m x86_64' to
override the architecture check that normally forbids this kind of
shenanigans,
in order to cross-build anything that uses libtool as a tool.
This is partly because libtool doesn't follow the normal GNU
convention of `./configure --build=<native platform> --host=<platform
package will run on> --target=<platform package is configured to
operate on>' -- in this example, build=amd64, host=amd64,
target=powerpc.
Instead, libtool expects to be cross-built itself, even if it's going
to run as a tool. It's not as bonkers as it sounds at first: libtool
is just a shell script, and it caches various information about the
(cross-building!) toolchain it is built with so it can use that
information later when it is run as a tool itself to cross-compile
other software.
To make this work, we need to create the toolchain wrappers for
libtool _as if_ we were cross-building even if we are building a
native package. So mk/tools uses a new flag TOOLS_USE_CROSS_COMPILE
instead of USE_CROSS_COMPILE, and libtool internally sets
MACHINE_ARCH=${TARGET_ARCH} (in the example above, powerpc) to make
it look like we're cross-building. The new TOOLS_CROSS_DESTDIR is an
alias for the (defaulted) CROSS_DESTDIR, which must now be set
unconditionally in mk.conf in order for libtool to know where the
cross-destdir will be; _CROSS_DESTDIR remains empty when building any
native packages (including the native cross-libtool package).
Finally, we need to make the resulting package be a native package,
with MACHINE_ARCH set to the one that it will be installed on (in the
example above, amd64), so I added an indirection _BUILD_DEFS.${var}
to replace var on its own in the build definitions that get baked
into the package, shown by `pkg_info -B'. Setting
_BUILD_DEFS.MACHINE_ARCH=${NATIVE_MACHINE_ARCH} ensures that this
mutant hybrid cross-built libtool still produces a native package.
All of this logic is gated on setting USE_CROSS_COMPILE in mk.conf or
LIBTOOL_CROSS_COMPILE in the package makefile, so it should be safe
for non-cross-builds -- when USE_CROSS_COMPILE=no and you're not
building cross-libtool, everything is as before.
This is needed by packages that require hand-holding in building PIE. Also a
post-build check for MKPIE is performed by default when PKG_DEVELOPER=YES.
gcc4.8,4.9,5 have bugs preventing them from being useful within pkgsrc
for the primary use case that finds them handy:
glibc + FORTIFY + those GCC versions = build failures.
Additionally, requiring fewer versions of GCC is an improvement for
the vast majority of use-cases considered.
We might want to bump this further than gcc6 later on, but this is a
big improvement for CentOS builds.
For USE_LANGUAGES there is already a pkglint warning, but for GCC_REQD it
is missing. It's better to have this check directly in the
infrastructure since it is more reliable.
This check is disabled by default, to not cause any new breakage.
It should be enabled in bulk builds.
A default installation of GCC doesn't install bin/cc but only bin/gcc.
Adding bin/cc is only done by the pgksrc packages, not by the upstream
package.
The previous strategy of just checking whether ${GCCBASE}/bin/${CC:[1]}
exists did not work in such a situation. Therefore, if CC still has its
default value from sys.mk, that is changed to the intended gcc, which
then detects the base GCC properly.
See https://mail-index.netbsd.org/pkgsrc-users/2019/09/07/msg029329.html.
See https://mail-index.netbsd.org/tech-pkg/2019/09/18/msg021976.html.
This way we don't inadvertently tell a native dependency that it is
supposed to be compiled with the cross-compiler.
No functional change intended for USE_CROSS_COMPILE=no.
Platform support is determined by _OPSYS_SUPPORTS_CTF from mk/platform, the
user enables support by setting PKGSRC_USE_CTF=yes, and packages can
explicitly disable support with CTF_SUPPORTED=no or skip certain files with
CTF_FILES_SKIP.
The path to ctfconvert is configured via TOOLS_PLATFORM.ctfconvert.
If all of the requisite variables are enabled, a compiler-specific debug flag
is passed via the wrappers to ensure we have DWARF information to convert,
_INSTALL_UNSTRIPPED is explicitly defined to avoid binaries being stripped
prior to conversion, and the conversion is performed during the install stage.
It is recommended that users who enable the feature also set STRIP_DEBUG=yes
to reduce the final binary size once the conversion has been performed.
This has been used for the past year in Joyent SmartOS builds. FreeBSD is
marked as supported but is untested.
