diff options
author | riastradh <riastradh@pkgsrc.org> | 2013-05-10 00:03:46 +0000 |
---|---|---|
committer | riastradh <riastradh@pkgsrc.org> | 2013-05-10 00:03:46 +0000 |
commit | 6b363b971f2416f493755b4c9bf6b9ae4b83d662 (patch) | |
tree | 2ad00a09d7568d22aa160b98b4b3e498a9b16531 /doc/HOWTO-dev-crosscompile | |
parent | 01f1c50dc5949e14cb6061dc9a08ba1af8ccc395 (diff) | |
download | pkgsrc-6b363b971f2416f493755b4c9bf6b9ae4b83d662.tar.gz |
Add some notes on how to use and develop cross-compiled packages.
ok agc
Diffstat (limited to 'doc/HOWTO-dev-crosscompile')
-rw-r--r-- | doc/HOWTO-dev-crosscompile | 87 |
1 files changed, 87 insertions, 0 deletions
diff --git a/doc/HOWTO-dev-crosscompile b/doc/HOWTO-dev-crosscompile new file mode 100644 index 00000000000..d89ba5b15a3 --- /dev/null +++ b/doc/HOWTO-dev-crosscompile @@ -0,0 +1,87 @@ +Cross-compilation in pkgsrc (developer's guide) -*- outline -*- +Taylor R. Campbell <riastradh@NetBSD.org> +2013-04-23 draft + +These are some notes on how to make your package cross-compilable. +There is no single recipe for it -- each package is different, and +even if it follows, say, the GNU build system conventions, it may have +its quirks, and the author of the software you're packaging may not +have ever thought of cross-compilation. + +* Native and target platform + +When building a package, MACHINE_ARCH, MACHINE_GNU_PLATFORM, &c., +describe the platform for which the package is being built. If +USE_CROSS_COMPILE=no, this is the native platform; otherwise, if +USE_CROSS_COMPILE=yes, it is the target platform, and the additional +variables NATIVE_MACHINE_ARCH, NATIVE_MACHINE_GNU_PLATFORM, &c., +describe the native platform. + +When building a native package for cross-compilation, such as a +compiler for the target, the variable TARGET_ARCH describes the target +platform like MACHINE_ARCH. If the build product varies with the +choice of target, then TARGET_ARCH should be embedded into the PKGNAME +somewhere so that the different build products are distinguished by +having different package names. + +XXX This pattern is incompletely realized. We should probably replace +TARGET_ARCH by TARGET_MACHINE_ARCH, TARGET_MACHINE_GNU_PLATFORM, &c., +and perhaps decide which of those is the main switch that you set when +you want to select cross-compilation. Ideally, this switch should +also support cross-compilation to other operating systems. + +* Specifying the toolchain + +Software built following GNU conventions can set GNU_CONFIGURE=yes so +that pkgsrc will automatically specify the right --build, --host, and +--target options for cross-compilation and point everything at the +right toolchain. + +XXX And software not built following GNU conventions...? + +* Tool dependencies + +If the process of building your package requires running programs, +loading libraries, using data, &c., from a native package, the native +package is a tool dependency, not (necessarily) a build dependency or +a normal dependency. For example, if building your package entails +transforming some XML with XSLT, you might add: + +TOOL_DEPENDS+= libxslt>=1.1.0:../../textproc/libxslt + +* Native C and C++ compilers + +Some software wants build tools written in C and C++ and then execute +them natively at build-time. Sometimes configure scripts or makefiles +accept a variable named CC_FOR_BUILD or similar to supply this; in +that case, you can pass in the pkgsrc make variables NATIVE_CC and +friends: + +CONFIGURE_ENV+= CC_FOR_BUILD=${NATIVE_CC:Q} +CONFIGURE_ENV+= CXX_FOR_BUILD=${NATIVE_CXX:Q} +CONFIGURE_ENV+= LD_FOR_BUILD=${NATIVE_LD:Q} + +If the software doesn't use CC_FOR_BUILD, it may still be easy to find +the makefile rules that invoke $(CC) or $(LD) to build native tools +and patch them to replace that by $(CC_FOR_BUILD) and $(LD_FOR_BUILD). + +XXX The mechanism here is currently pretty kludgey; there is little +principle to these NATIVE_CC/CXX/LD variables and they should be +better rationalized. If you want a native Fortran compiler, for +instance, you'll have to hack it yourself. + +* Configure-time run-tests + +There's a lot of autoconf-configured software out there that uses +run-tests to learn about the environment, which doesn't work so well +in cross-builds. Some of these can be patched to be replaced by +compile-tests; otherwise, for a particular known target environment, +you can pre-answer the tests for autoconf: + +.include "../../bsd.prefs.mk" + +.if ${OPSYS} == "NetBSD" +# Configure wants to check for /dev/random but can't. We know NetBSD +# always has a /dev/random, so inform autoconf of the fact. +CONFIGURE_ENV+= ac_cv_file__dev_random=yes +.endif |