| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The update to ccache4 caused a large increase in dependencies,
breaking builds using e.g. "PKGSRC_COMPILER=ccache gcc", and the
pre-update discussion of consequences and how to deal with it did not
occur.
The right long-term solution is to have a variable to select which
ccache is used, and per-version circular dependency lists, accomoding
both those who wish to use ccache 3 on low-resource machines and those
who wish to use ccache 4.
With 20224 branch manager hat on, I don't want to deal with ccache
instability (or any instability at all now that we are past 12/1), so
I have set ccache.mk to depend on ccache3, the status quo ante
argumentum.
Note that if one has any ccache installed, it will be used, so people
that want to use ccache4 can just install it and then flip on
"PKGSRC_COMPILER=ccache gcc".
|
|
|
|
Each GCC_REQD entry has an associated cost as it invokes pkg_admin to see
if it's suitable, so only add 2.8.0 and 3.0 when absolutely necessary.
|
|
|
|
Reported to cause problems on FreeBSD, and clang is generally pretty
aggressive about defaulting to newer versions anyway.
|
|
Possible performance improvement, no funtional change.
|
|
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.
|
|
|
|
workaround PR pkg/56679
|
|
There's no guarantee that POSSIBLE_GFORTRAN_VERSION is a numeric value,
so cannot be compared as such. For example on my macOS it is set to
"clang-12 (clang-1205.0.22.9)".
This really needs to be normalised correctly at some point.
|
|
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.
|
|
broken on 32-bit arm.
|
|
|
|
|
|
joerg says clang has the same interface for this like gcc
|
|
Prior to this change PKGSRC_MKPIE was silently ignored when clang was chosen for
the compiler, i.e. executables were never built as PIE. This became an error
after introducing a post-build check for it.
Of course we should add a MKPIE support for clang, but for now we just emit a
warning. Otherwise we cannot build packages such as devel/gnustep-base which
requires clang to build.
|
|
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.
|
|
NetBSD/mips.
PR pkg/56559
|
|
cause any noticable breakage.
|
|
Should improve readability and in some cases avoid potential failure due to
string comparisons being used. No other functional change intended.
|
|
substantial changes to infrastructure and testing can be performed
to ensure it's applied universally without breaking anything
|
|
remaining packages that fail to build with RELRO that were uncaught
by my original bulk builds due to CHECK_RELRO failing to work (sorry...)
|
|
This helps certain X.Org modules.
|
|
|
|
prevents mangling by wrappers in mysterious circumstances
|
|
|
|
|
|
PR pkg/56337
|
|
|
|
most of these simply extend matching from "aarch64" to "aarch64eb"
in various forms of code. most remaining uses in pkgsrc of
"MACHINE_ARCH == aarch64" are because of missing aarch64eb support,
such as most of the binary-bootstrap requiring languages like rust,
go, and java.
no pkg-bump because this shouldn't change packages on systems that
could already build all of these.
|
|
|
|
|
|
|
|
|
|
(Apparently left over from reducing the vast number of gcc versions.)
|
|
|
|
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.
|
|
Noted by Jackson Bryn in PR 55842.
|
|
|
|
lang/gcc8 has patches for NetBSD/aarch64 and lang/gcc10 has support mostly
upstreamed. Nobody seems interested in fixing gcc9, but the pkgsrc
logic defaults to it when the system compiler is GCC 9 which leads to
broken fortran packages. Let's just skip forward to gcc10.
|
|
In lint mode, NetBSD's make is stricter about undefined variables. In
conditions, the function arguments must be fully defined.
|
|
-Werror=implicit-function-declaration, which will be great someday when
we're ready for it. Until then, on macOS, detect this situation and tell
the cc wrapper to prepend -Wno-error=implicit-function-declaration.
Taking mail/qmail as our example, this fixes the build on Catalina
with "Apple clang version 12.0.0 (clang-1200.0.32.2)". Adding
-Werror=implicit-function-declaration to CPPFLAGS or CFLAGS (in
mk.conf or on the command line) re-fails the build, as expected, with
a pile of "error: implicit declaration of function". Also as expected,
a full -Werror fails earlier on one of the many other problems with
qmail's code.
For clang on non-macOS platforms, no change.
clang-and-wrapper-ok: joerg@
during-the-freeze-ok: gdt@
|
|
A pert of PR pkg/55637.
|
|
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.
|
|
As with clang. Default got flipped with v10.
|
|
Caused SSP flags to be omitted in GCC 10. Check flipped because all new
GCC versions can be expected to support it.
|
