diff options
author | riastradh <riastradh@pkgsrc.org> | 2022-04-04 11:23:06 +0000 |
---|---|---|
committer | riastradh <riastradh@pkgsrc.org> | 2022-04-04 11:23:06 +0000 |
commit | 73c4eb1d0670b65afa7e80a35ffb56b7173c700b (patch) | |
tree | ce0871b7242b6bc4e15b7e30718de1a82186fe05 /cross | |
parent | f59201716cdf618577c3e831414020db7e8d5974 (diff) | |
download | pkgsrc-73c4eb1d0670b65afa7e80a35ffb56b7173c700b.tar.gz |
mk: Cross-eyed hacks to support cross-libtool.
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.
Diffstat (limited to 'cross')
-rw-r--r-- | cross/cross-libtool-base/Makefile | 6 |
1 files changed, 4 insertions, 2 deletions
diff --git a/cross/cross-libtool-base/Makefile b/cross/cross-libtool-base/Makefile index 1d1571ac464..997588bfca0 100644 --- a/cross/cross-libtool-base/Makefile +++ b/cross/cross-libtool-base/Makefile @@ -1,4 +1,4 @@ -# $NetBSD: Makefile,v 1.5 2021/05/24 19:49:26 wiz Exp $ +# $NetBSD: Makefile,v 1.6 2022/04/04 11:23:06 riastradh Exp $ # XXX This is kludgerific copypasta of devel/libtool-base/Makefile for # cross-compilation. Please make it go away! @@ -31,12 +31,14 @@ ########################################################################### ########################################################################### +LIBTOOL_CROSS_COMPILE= yes + .include "../../devel/libtool/Makefile.common" # XXX Tweaked for cross-compilation. #PKGNAME= ${DISTNAME:S/-/-base-/} PKGNAME= ${DISTNAME:S/^libtool-/cross-libtool-base-${MACHINE_ARCH}-/} -PKGREVISION= 6 +PKGREVISION= 7 COMMENT= Generic shared library support script (the script itself) |