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.
Explain that we should probably use cmake's RPATH support instead of
turning it off and passing it via LDFLAGS, but that this change seems
somewhat risky.
(This is a comment-only change.)
Fixes builds inside an x86_64 chroot where packages add x86-specific flags
based on the output of uname even though we're building for aarch64. CMake
provides the CMAKE_APPLE_SILICON_PROCESSOR variable for this situation.
The rewritten check for unknown configure options already checks for
options that are not defined anywhere. After that, the configure scripts
don't need to check for these options anymore since all remaining options
are known to the package, in at least one of its configure scripts.
The previous implementation could not reliably detect outdated configure
options. This was apparent in devel/gettext-tools, where the option
--with-included-libcroco had become unknown between May 2019 and May
2020, but the check was not run.
The behavior is the same in the pkgsrc default configuration. Only if
GNU_CONFIGURE_STRICT=yes, the new check is activated and will make
packages fail that previously succeeded to build. Since that variable is
not widely known, there won't be much sudden breakage, if any.
There are several places in pkgsrc where the files to be patched are
listed individually instead of just saying util/*/*.sh. This is
unnecessarily detailed. Encourage package authors to use filename
patterns more often.
An example is REPLACE_PYTHON in lang/clang, which currently fails because
some of the listed files don't exist anymore.
This allows easy inspection of the realistic environment in which the
configure scripts are run.
The code is copied from the similar build-env target.
This might help to find the cause for pkg/54894, where "gcc -dumpversion"
is said to output 0 as the version number.
When "bmake clean depends" was called for a package where the various
cookie files already existed, these would enable different rules than a
clean package directory.
Since "bmake clean" deletes all the cookie files before "bmake depends"
starts, in these combined command lines the cookie files must be treated
as absent.
This helps to find out which of the several configure scripts has
problems, for example when checking for unknown command line options
using GNU_CONFIGURE_STRICT.
When a Makefile fragment contains $0, this means a Makefile variable, not
a shell or AWK variable.
The bug in ccc.mk survived unnoticed for almost 15 years. The bug in
gnu-configure.mk for MirBSD got only half as old.
When a GNU configure script is run with unknown --enable, --disable,
--with or --without options, it doesn't fail but just prints a warning.
This hides outdated package definitions that may still pass options that
have been removed already.
See https://mail-index.netbsd.org/pkgsrc-users/2019/04/02/msg028272.html
for a recent case.
The default behavior doesn't change. After a period of testing this new
check, the check is expected to become enabled by default so that future
problems like this are prevented.
Up to now, there was a central list of variable name patterns that
defined whether a variable was printed as a sorted list, as a list or as
a single value.
Now each variable group decides on its own which of the variables are
printed in which way, using the usual glob patterns. This is more
flexible since different files sometimes differ in their naming
conventions.
Two variable groups are added: license (for everything related to
LICENSE) and go (for lang/go).
CMAKE_PKGSRC_BUILD_FLAGS
If set to yes, disable compiler optimization flags associated
with the CMAKE_BUILD_TYPE setting (for pkgsrc these come in from
the user via variables like CFLAGS). The default is yes, but you can
set it to no for pkgsrc packages that do not use a compiler to avoid
cmake "Manually-specified variables were not used by the project"
warnings associated with this variable.
Changes since 2.4.2 are too numerous to mention, with over 4,700 lines
in the ChangeLog file. However, this release does at least fix a large
number of build failures on SmartOS, and doesn't appear to cause any
obvious regressions in bulk builds performed by Joerg and myself.
Some pkgsrc cleanups while here, including merging the MirBSD patches
correctly. It couldn't be made much clearer how to properly integrate
patches here to ensure they are not lost. Next time you might not be so
fortunate!
By default CMAKE_INSTALL_PREFIX points to PREFIX, but some software requres
custom subprefix. At least blender and brlcad are in this category.
To set new prefix it's sufficient to set CMAKE_INSTALL_PREFIX in a package,
for example (in brlcad):
CMAKE_INSTALL_PREFIX=${PREFIX}/brlcad
Reviewed by <joerg> and <jperkin>.
conflict with pkgsrc versions of those packages, and do not interact well
with the wrappers anyway as cmake will perform simple file-based tests for
headers but the compiler will be unable to find them.
overrides for libtool. This allows us to easily get the fixed version
from our libtool in place without having to hunt down for the specific
bugs in random places. Disable the override explicitly in clisp, which
installs a copy without explicitly depending on libtool at run time.
wrapped version by full path. This fixes some cases where the wrappers
have been bypassed. lang/lua52 triggered the investigation as it failed
to link against libreadline, which should have been translated to
libedit. Tested by jperkin and myself with full bulk builds.
