marvin.weiler
/
musl-cross-make
mirror of https://github.com/richfelker/musl-cross-make.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
musl-cross-make/litecross/Makefile

284 lines
7.7 KiB
Makefile
Raw Normal View History

overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
Use $(CURDIR) instead of $(PWD) in Makefile Some shells (in particular ksh) don't export PWD by default, so it doesn't end up as a make variable.
2016-12-02 08:14:01 +01:00
OUTPUT = $(CURDIR)/output
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
BINUTILS_SRCDIR = BINUTILS_SRCDIR_not_set
GCC_SRCDIR = GCC_SRCDIR_not_set
MUSL_SRCDIR = MUSL_SRCDIR_not_set
litecross: eliminate obstacles to toolchain config from make command line the += approach which worked in config.mak does not work well if the user wants to pass in configure options from the command line. restructure configure command line construction such that setting COMMON_CONFIG, GCC_CONFIG, or TOOLCHAIN_CONFIG from the command line does not suppress necessary defaults.
2016-07-08 04:19:14 +02:00
GCC_CONFIG_FOR_TARGET =
COMMON_CONFIG =
GCC_CONFIG =
TOOLCHAIN_CONFIG =
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
XGCC_DIR = ../obj_gcc/gcc
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
XGCC = $(XGCC_DIR)/xgcc -B $(XGCC_DIR)
litecross: fix $(TARGET)-based config when value comes from config.mak commit 03bd65562a509ff86bfe8861f8e51e973bcfdd3b wrongly placed the logic conditional on $(TARGET) before inclusion of config.mak, so that it only worked when TARGET was set from the make command line or environment. reorder to fix.
2016-06-22 20:32:56 +02:00
-include config.mak
litecross: build target config logic into the makefile leaving necessary configuration options for certain targets to the user is error-prone and inconvenient. instead of configuration for exact target string matchs in the sample config.mak, provide general logic in the makefile itself which should cover all variants as well.
2016-05-19 05:15:32 +02:00
ifneq ($(findstring fdpic,$(TARGET)),)
litecross: eliminate obstacles to toolchain config from make command line the += approach which worked in config.mak does not work well if the user wants to pass in configure options from the command line. restructure configure command line construction such that setting COMMON_CONFIG, GCC_CONFIG, or TOOLCHAIN_CONFIG from the command line does not suppress necessary defaults.
2016-07-08 04:19:14 +02:00
GCC_CONFIG_FOR_TARGET += --enable-fdpic
litecross: build target config logic into the makefile leaving necessary configuration options for certain targets to the user is error-prone and inconvenient. instead of configuration for exact target string matchs in the sample config.mak, provide general logic in the makefile itself which should cover all variants as well.
2016-05-19 05:15:32 +02:00
endif
ifneq ($(filter x86_64%x32,$(TARGET)),)
litecross: eliminate obstacles to toolchain config from make command line the += approach which worked in config.mak does not work well if the user wants to pass in configure options from the command line. restructure configure command line construction such that setting COMMON_CONFIG, GCC_CONFIG, or TOOLCHAIN_CONFIG from the command line does not suppress necessary defaults.
2016-07-08 04:19:14 +02:00
GCC_CONFIG_FOR_TARGET += --with-abi=x32
litecross: build target config logic into the makefile leaving necessary configuration options for certain targets to the user is error-prone and inconvenient. instead of configuration for exact target string matchs in the sample config.mak, provide general logic in the makefile itself which should cover all variants as well.
2016-05-19 05:15:32 +02:00
endif
add necessary gcc abi config for powerpc64 targets
2016-12-29 20:40:40 +01:00
ifneq ($(findstring powerpc64,$(TARGET)),)
GCC_CONFIG_FOR_TARGET += --with-abi=elfv2
endif
litecross: build target config logic into the makefile leaving necessary configuration options for certain targets to the user is error-prone and inconvenient. instead of configuration for exact target string matchs in the sample config.mak, provide general logic in the makefile itself which should cover all variants as well.
2016-05-19 05:15:32 +02:00
ifneq ($(findstring mips64,$(TARGET))$(findstring mipsisa64,$(TARGET)),)
ifneq ($(findstring n32,$(TARGET)),)
litecross: eliminate obstacles to toolchain config from make command line the += approach which worked in config.mak does not work well if the user wants to pass in configure options from the command line. restructure configure command line construction such that setting COMMON_CONFIG, GCC_CONFIG, or TOOLCHAIN_CONFIG from the command line does not suppress necessary defaults.
2016-07-08 04:19:14 +02:00
GCC_CONFIG_FOR_TARGET += --with-abi=n32
litecross: build target config logic into the makefile leaving necessary configuration options for certain targets to the user is error-prone and inconvenient. instead of configuration for exact target string matchs in the sample config.mak, provide general logic in the makefile itself which should cover all variants as well.
2016-05-19 05:15:32 +02:00
else
litecross: eliminate obstacles to toolchain config from make command line the += approach which worked in config.mak does not work well if the user wants to pass in configure options from the command line. restructure configure command line construction such that setting COMMON_CONFIG, GCC_CONFIG, or TOOLCHAIN_CONFIG from the command line does not suppress necessary defaults.
2016-07-08 04:19:14 +02:00
GCC_CONFIG_FOR_TARGET += --with-abi=64
litecross: build target config logic into the makefile leaving necessary configuration options for certain targets to the user is error-prone and inconvenient. instead of configuration for exact target string matchs in the sample config.mak, provide general logic in the makefile itself which should cover all variants as well.
2016-05-19 05:15:32 +02:00
endif
endif
fix build for s390x due to wrong long double ABI default musl uses IEEE quad for long double on s390x. current versions check for mismatch and hard fail at configure time if the compiler is wrong. with older versions, mcm silently produced a broken toolchain/libc.
2018-02-28 16:36:47 +01:00
ifneq ($(findstring s390x,$(TARGET)),)
GCC_CONFIG_FOR_TARGET += --with-long-double-128
endif
litecross: build target config logic into the makefile leaving necessary configuration options for certain targets to the user is error-prone and inconvenient. instead of configuration for exact target string matchs in the sample config.mak, provide general logic in the makefile itself which should cover all variants as well.
2016-05-19 05:15:32 +02:00
ifneq ($(filter %sf,$(TARGET)),)
litecross: eliminate obstacles to toolchain config from make command line the += approach which worked in config.mak does not work well if the user wants to pass in configure options from the command line. restructure configure command line construction such that setting COMMON_CONFIG, GCC_CONFIG, or TOOLCHAIN_CONFIG from the command line does not suppress necessary defaults.
2016-07-08 04:19:14 +02:00
GCC_CONFIG_FOR_TARGET += --with-float=soft
litecross: build target config logic into the makefile leaving necessary configuration options for certain targets to the user is error-prone and inconvenient. instead of configuration for exact target string matchs in the sample config.mak, provide general logic in the makefile itself which should cover all variants as well.
2016-05-19 05:15:32 +02:00
endif
ifneq ($(filter %hf,$(TARGET)),)
litecross: eliminate obstacles to toolchain config from make command line the += approach which worked in config.mak does not work well if the user wants to pass in configure options from the command line. restructure configure command line construction such that setting COMMON_CONFIG, GCC_CONFIG, or TOOLCHAIN_CONFIG from the command line does not suppress necessary defaults.
2016-07-08 04:19:14 +02:00
GCC_CONFIG_FOR_TARGET += --with-float=hard
litecross: build target config logic into the makefile leaving necessary configuration options for certain targets to the user is error-prone and inconvenient. instead of configuration for exact target string matchs in the sample config.mak, provide general logic in the makefile itself which should cover all variants as well.
2016-05-19 05:15:32 +02:00
endif
support using an alternate libtool utility, such as slibtool.
2018-02-28 03:56:48 +01:00
ifneq ($(LIBTOOL),)
slibtool support: remove the LIBTOOL_STATIC_ARG var (no longer needed). Beginning with slibtool version 0.5.26 and the introduction of the rlibtool symlink (the equivalent of slibtool --heuristics), slibtool may now be told to automatically detect its desired operation mode (share-only, static-only, or both) by way of parsing the generated libtool script which it replaces.
2018-10-30 04:01:00 +01:00
LIBTOOL_ARG = LIBTOOL=$(LIBTOOL)
support using an alternate libtool utility, such as slibtool.
2018-02-28 03:56:48 +01:00
endif
litecross: build target config logic into the makefile leaving necessary configuration options for certain targets to the user is error-prone and inconvenient. instead of configuration for exact target string matchs in the sample config.mak, provide general logic in the makefile itself which should cover all variants as well.
2016-05-19 05:15:32 +02:00
litecross: always disable multilib, suppress lib64, etc. dir structures multilib would not be usable without building multiple versions of musl anyway, which we don't yet support, so enabling it does not make sense. due to bugs in gcc's build system, even with multilib disabled, multilib dir structures get used on 64-bit archs leading to target libs being installed in /lib64 (or /libx32, etc.) under the sysroot, rather than /lib. fix this by suppressing the variable that controls it.
2016-05-06 07:29:07 +02:00
MAKE += MULTILIB_OSDIRNAMES=
fix suppression of info installation blanking INFO_DEPS suffices to prevent attempts to rebuild the docs, but does not reliably suppress their installation. blanking infodir does the latter. there are other methods that work too but this seems to be the simplest.
2016-05-03 06:28:26 +02:00
MAKE += INFO_DEPS= infodir=
fix wrong ac_cv_prog_lex_root value the value should only be the root, not including the .c suffix. as noted in commit 2d0015f547b1846eeab1359f5e8ce493d2be50f9 which added this, the result is not actually used, so it doesn't matter that it's wrong, but the wrong value produces spurious error output in configure logs.
2020-01-30 05:06:02 +01:00
MAKE += ac_cv_prog_lex_root=lex.yy
further suppress generation of info docs with latest gcc, info files were appearing in the top-level install directory. this seems to make them go away again.
2016-12-14 18:42:16 +01:00
MAKE += MAKEINFO=false
suppress info build and installation, remove texinfo dependency
2016-05-02 20:19:19 +02:00
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
FULL_BINUTILS_CONFIG = \
make --disable-separate-code the default for binutils the default is ordered such that user-provided config variables in config.mak or on the make command line can still override it. this is a dubious anti-ROP feature with high cost (file size, load time, VMA count consumed per library), and historically was broken in some binutils versions. the ones we use don't seem to be affected, but it's better to have it off anyway.
2019-07-16 21:02:31 +02:00
--disable-separate-code \
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
$(COMMON_CONFIG) $(BINUTILS_CONFIG) $(TOOLCHAIN_CONFIG) \
--disable-werror \
--target=$(TARGET) --prefix= \
--libdir=/lib --disable-multilib \
litecross: Pass --enable-deterministic-archives to binutils, not gcc When the gcc and binutils build trees were separated in defdbb4505, --enable-deterministic-archives was accidentally left in FULL_GCC_CONFIG. This had the effect of reverting commit e83fe4b8ce, breaking reproducible builds (unless it was specified explicitly in config.mak).
2018-11-06 07:36:55 +01:00
--with-sysroot=$(SYSROOT) \
--enable-deterministic-archives
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
FULL_GCC_CONFIG = --enable-languages=c,c++ \
litecross: eliminate obstacles to toolchain config from make command line the += approach which worked in config.mak does not work well if the user wants to pass in configure options from the command line. restructure configure command line construction such that setting COMMON_CONFIG, GCC_CONFIG, or TOOLCHAIN_CONFIG from the command line does not suppress necessary defaults.
2016-07-08 04:19:14 +02:00
$(GCC_CONFIG_FOR_TARGET) \
$(COMMON_CONFIG) $(GCC_CONFIG) $(TOOLCHAIN_CONFIG) \
pass --disable-bootstrap to gcc this should be a nop since we're either building a cross compiler or cross compiling, but due to recent gcc's config.guess detecting musl, it's possible to spuriously get $build=$host=$target, and then the dreaded bootstrap procedure runs and breaks the output.
2020-02-03 07:07:22 +01:00
--disable-bootstrap \
pass --disable-assembly to gcc configure, for gmp gmp does not build correctly with compilers that default to emitting PIE/PIC, due to custom-preprocessed asm source files which have wrong logic for determining if PIC-compatibility is needed. ideally this would be patched in gmp, but I don't know how to do that, so for the time being, just disable the asm.
2020-02-03 20:27:19 +01:00
--disable-assembly \
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
--disable-werror \
--target=$(TARGET) --prefix= \
litecross: always disable multilib, suppress lib64, etc. dir structures multilib would not be usable without building multiple versions of musl anyway, which we don't yet support, so enabling it does not make sense. due to bugs in gcc's build system, even with multilib disabled, multilib dir structures get used on 64-bit archs leading to target libs being installed in /lib64 (or /libx32, etc.) under the sysroot, rather than /lib. fix this by suppressing the variable that controls it.
2016-05-06 07:29:07 +02:00
--libdir=/lib --disable-multilib \
litecross: add support for cross-compiling a native toolchain experimental feature. activated by setting NATIVE make var. cross-compiler for the host/target system must already be installed at a location in PATH.
2016-05-06 05:00:35 +02:00
--with-sysroot=$(SYSROOT) \
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
--enable-tls \
litecross: add some gcc options that should always be used with musl libmpx is broken in all gcc versions that have it (not supported yet by mcm/litecross, but will be). ifunc is not supported by musl and won't be unless/until the contract for resolvers can be specified clearly in a way that real-world usage is safe and does not require lazy binding; having it enabled at gcc level reportedly produces a broken libatomic. explicitly enabling libstdcxx-time is needed to get libc clock_gettime (with vdso support) to be used in libstdc++; it's disabled by default because of glibc legacy practice of having clock_gettime in librt, which depends on glibc's libpthread and undermines libstdc++'s (invalid use of) weak references to pthread symbols.
2016-05-06 20:37:09 +02:00
--disable-libmudflap --disable-libsanitizer \
--disable-gnu-indirect-function \
--disable-libmpx \
work around gcc libstdc++ time64 incompatibility with the default --enable-libstdcxx-time, libstdc++'s configure probes for the existence of a clock_gettime syscall and sets up the time API implementation to make direct syscalls, presumably as a workaround for old glibc tucking away the clock_gettime function in librt, which in turn depends on libpthread. this breaks since struct timespec does not match the syscall's interface on 32-bit archs. passing --enable-libstdcxx-time=rt forces different configure paths that correctly use the public clock_gettime function and librt if needed. this issue should be patched in gcc rather than worked around via configure options, but I'd rather wait to patch until I understand how to fix it correctly and produce a patch that's acceptable to upstream and distros.
2020-01-19 18:40:04 +01:00
--enable-libstdcxx-time=rt
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
litecross: add support for cross-compiling a native toolchain experimental feature. activated by setting NATIVE make var. cross-compiler for the host/target system must already be installed at a location in PATH.
2016-05-06 05:00:35 +02:00
FULL_MUSL_CONFIG = $(MUSL_CONFIG) \
--prefix= --host=$(TARGET)
add support for canadian-cross builds, reorganize dirs to avoid clashes cross (or native) compilers meant to be run on a host different from the build environment can now be built by setting the HOST make variable on the command line or in config.mak. this requires (for building the target libraries) a cross toolchain for the same TARGET, but that can run on the build system, to be present already in the PATH. future enhancements may make it possible to automatically build and use the needed toolchain. leaving HOST blank produces a toolchain that runs on the build system (host==build in gcc jargon), the same as before with NATIVE unset. the NATIVE make variable is now obsolete but still supported; it simply causes HOST to be set equal to TARGET (thus producing a native toolchain for the target). builds are now placed in build/$(HOST)/$(TARGET) when HOST is set, and build/local/$(TARGET) when it's not, so that builds for the same target but different host do not clobber each other. default OUTPUT directory when HOST is set is now output-$(HOST). as usual, multiple targets can safely go in the same output directory, but toolchains for different hosts should not.
2017-06-11 01:47:23 +02:00
ifneq ($(NATIVE),)
HOST:=$(TARGET)
endif
force cross compiler/cross compiling now that config.guess knows how to detect musl, it's possible when building on a musl-based system that $build will spuriously match $target, preventing the desired behavior of building as a cross compiler or as a cross-compiled native compiler. run config.guess and config.sub from the litecross makefile to check if $build is going to match $target, and if so, append junk to the libc/abi part of the $build tuple so that it no longer matches.
2020-02-03 07:09:08 +01:00
ifeq ($(BUILD),)
GUESS = $(shell cd $(GCC_SRCDIR) && ./config.guess)
TARGET_CANON = $(shell cd $(GCC_SRCDIR) && ./config.sub $(TARGET))
BUILD = $(GUESS)$(if $(subst $(TARGET_CANON),,$(GUESS)),,xx)
endif
add support for canadian-cross builds, reorganize dirs to avoid clashes cross (or native) compilers meant to be run on a host different from the build environment can now be built by setting the HOST make variable on the command line or in config.mak. this requires (for building the target libraries) a cross toolchain for the same TARGET, but that can run on the build system, to be present already in the PATH. future enhancements may make it possible to automatically build and use the needed toolchain. leaving HOST blank produces a toolchain that runs on the build system (host==build in gcc jargon), the same as before with NATIVE unset. the NATIVE make variable is now obsolete but still supported; it simply causes HOST to be set equal to TARGET (thus producing a native toolchain for the target). builds are now placed in build/$(HOST)/$(TARGET) when HOST is set, and build/local/$(TARGET) when it's not, so that builds for the same target but different host do not clobber each other. default OUTPUT directory when HOST is set is now output-$(HOST). as usual, multiple targets can safely go in the same output directory, but toolchains for different hosts should not.
2017-06-11 01:47:23 +02:00
ifeq ($(HOST),)
litecross: add support for cross-compiling a native toolchain experimental feature. activated by setting NATIVE make var. cross-compiler for the host/target system must already be installed at a location in PATH.
2016-05-06 05:00:35 +02:00
SYSROOT = /$(TARGET)
force cross compiler/cross compiling now that config.guess knows how to detect musl, it's possible when building on a musl-based system that $build will spuriously match $target, preventing the desired behavior of building as a cross compiler or as a cross-compiled native compiler. run config.guess and config.sub from the litecross makefile to check if $build is going to match $target, and if so, append junk to the libc/abi part of the $build tuple so that it no longer matches.
2020-02-03 07:09:08 +01:00
FULL_BINUTILS_CONFIG += --build=$(BUILD) --host=$(BUILD)
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
FULL_GCC_CONFIG += --with-build-sysroot=$(CURDIR)/obj_sysroot \
AR_FOR_TARGET=$(PWD)/obj_binutils/binutils/ar \
AS_FOR_TARGET=$(PWD)/obj_binutils/gas/as-new \
LD_FOR_TARGET=$(PWD)/obj_binutils/ld/ld-new \
NM_FOR_TARGET=$(PWD)/obj_binutils/binutils/nm-new \
OBJCOPY_FOR_TARGET=$(PWD)/obj_binutils/binutils/objcopy \
OBJDUMP_FOR_TARGET=$(PWD)/obj_binutils/binutils/objdump \
RANLIB_FOR_TARGET=$(PWD)/obj_binutils/binutils/ranlib \
READELF_FOR_TARGET=$(PWD)/obj_binutils/binutils/readelf \
STRIP_FOR_TARGET=$(PWD)/obj_binutils/binutils/strip-new \
force cross compiler/cross compiling now that config.guess knows how to detect musl, it's possible when building on a musl-based system that $build will spuriously match $target, preventing the desired behavior of building as a cross compiler or as a cross-compiled native compiler. run config.guess and config.sub from the litecross makefile to check if $build is going to match $target, and if so, append junk to the libc/abi part of the $build tuple so that it no longer matches.
2020-02-03 07:09:08 +01:00
--build=$(BUILD) --host=$(BUILD) \
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
# end
FULL_MUSL_CONFIG += CC="$(XGCC)" LIBCC="../obj_gcc/$(TARGET)/libgcc/libgcc.a"
MUSL_VARS = AR=../obj_binutils/binutils/ar RANLIB=../obj_binutils/binutils/ranlib
obj_musl/.lc_configured: | obj_gcc/gcc/.lc_built
obj_musl/.lc_built: | obj_gcc/$(TARGET)/libgcc/libgcc.a
obj_gcc/gcc/.lc_built: | obj_sysroot/usr obj_sysroot/lib32 obj_sysroot/lib64 obj_sysroot/include
obj_gcc/.lc_built: | obj_sysroot/.lc_libs obj_sysroot/.lc_headers
obj_gcc/.lc_configured: obj_binutils/.lc_built
litecross: add support for cross-compiling a native toolchain experimental feature. activated by setting NATIVE make var. cross-compiler for the host/target system must already be installed at a location in PATH.
2016-05-06 05:00:35 +02:00
else
SYSROOT = /
force cross compiler/cross compiling now that config.guess knows how to detect musl, it's possible when building on a musl-based system that $build will spuriously match $target, preventing the desired behavior of building as a cross compiler or as a cross-compiled native compiler. run config.guess and config.sub from the litecross makefile to check if $build is going to match $target, and if so, append junk to the libc/abi part of the $build tuple so that it no longer matches.
2020-02-03 07:09:08 +01:00
FULL_BINUTILS_CONFIG += --build=$(BUILD) --host=$(HOST)
FULL_GCC_CONFIG += --build=$(BUILD) --host=$(HOST)
litecross: add support for cross-compiling a native toolchain experimental feature. activated by setting NATIVE make var. cross-compiler for the host/target system must already be installed at a location in PATH.
2016-05-06 05:00:35 +02:00
MUSL_VARS =
endif
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
ifeq ($(TARGET),)
all:
@echo TARGET must be set.
@exit 1
install: all
else
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
all: musl gcc binutils
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
install: install-musl install-gcc install-binutils
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
musl: obj_musl/.lc_built
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
toolchain: gcc binutils
install-toolchain: install-gcc install-binutils
gcc: obj_gcc/.lc_built
binutils: obj_binutils/.lc_built
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
.PHONY: all musl toolchain install-musl install-toolchain clean
src_binutils: | $(BINUTILS_SRCDIR)
ln -sf $(BINUTILS_SRCDIR) $@
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
src_gcc_base: | $(GCC_SRCDIR)
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
ln -sf $(GCC_SRCDIR) $@
src_musl: | $(MUSL_SRCDIR)
ln -sf $(MUSL_SRCDIR) $@
litecross: accept empty {GMP,MPC,MPFR}_SRCDIR to use pre-installed ones
2016-05-02 19:45:22 +02:00
ifneq ($(GMP_SRCDIR),)
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
src_gcc: src_gmp
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
src_gmp: | $(GMP_SRCDIR)
ln -sf "$(GMP_SRCDIR)" $@
litecross: accept empty {GMP,MPC,MPFR}_SRCDIR to use pre-installed ones
2016-05-02 19:45:22 +02:00
endif
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
litecross: accept empty {GMP,MPC,MPFR}_SRCDIR to use pre-installed ones
2016-05-02 19:45:22 +02:00
ifneq ($(MPC_SRCDIR),)
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
src_gcc: src_mpc
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
src_mpc: | $(MPC_SRCDIR)
ln -sf "$(MPC_SRCDIR)" $@
litecross: accept empty {GMP,MPC,MPFR}_SRCDIR to use pre-installed ones
2016-05-02 19:45:22 +02:00
endif
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
litecross: accept empty {GMP,MPC,MPFR}_SRCDIR to use pre-installed ones
2016-05-02 19:45:22 +02:00
ifneq ($(MPFR_SRCDIR),)
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
src_gcc: src_mpfr
fix small copy&paste error in litecross makefile dependencies
2016-05-02 07:36:54 +02:00
src_mpfr: | $(MPFR_SRCDIR)
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
ln -sf "$(MPFR_SRCDIR)" $@
litecross: accept empty {GMP,MPC,MPFR}_SRCDIR to use pre-installed ones
2016-05-02 19:45:22 +02:00
endif
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
add optional isl support for advanced loop optimizations isl-0.15 does not work before gcc-5.3.0, for older gcc try isl-0.14.1
2016-05-22 13:27:05 +02:00
ifneq ($(ISL_SRCDIR),)
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
src_gcc: src_isl
add optional isl support for advanced loop optimizations isl-0.15 does not work before gcc-5.3.0, for older gcc try isl-0.14.1
2016-05-22 13:27:05 +02:00
src_isl: | $(ISL_SRCDIR)
ln -sf "$(ISL_SRCDIR)" $@
endif
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
src_gcc: src_gcc_base
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
rm -rf $@ $@.tmp
mkdir $@.tmp
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
cd $@.tmp && ln -sf ../src_gcc_base/* .
litecross: accept empty {GMP,MPC,MPFR}_SRCDIR to use pre-installed ones
2016-05-02 19:45:22 +02:00
$(if $(GMP_SRCDIR),cd $@.tmp && ln -sf ../src_gmp gmp)
$(if $(MPC_SRCDIR),cd $@.tmp && ln -sf ../src_mpc mpc)
$(if $(MPFR_SRCDIR),cd $@.tmp && ln -sf ../src_mpfr mpfr)
add optional isl support for advanced loop optimizations isl-0.15 does not work before gcc-5.3.0, for older gcc try isl-0.14.1
2016-05-22 13:27:05 +02:00
$(if $(ISL_SRCDIR),cd $@.tmp && ln -sf ../src_isl isl)
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
mv $@.tmp $@
obj_%:
mkdir -p $@
obj_sysroot/include:
mkdir -p $@
obj_sysroot/usr: | obj_sysroot
ln -sf . $@
litecross: add dummy lib32 symlink to lib in build sysroot at least mips n32 target seems to be breaking due to an expectation of finding crti.o/crtn.o there during building of target libs.
2017-06-11 03:24:12 +02:00
obj_sysroot/lib32: | obj_sysroot
ln -sf lib $@
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
obj_sysroot/lib64: | obj_sysroot
ln -sf lib $@
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
obj_binutils/.lc_configured: | obj_binutils src_binutils
cd obj_binutils && ../src_binutils/configure $(FULL_BINUTILS_CONFIG)
touch $@
obj_binutils/.lc_built: | obj_binutils/.lc_configured
slibtool support: remove the LIBTOOL_STATIC_ARG var (no longer needed). Beginning with slibtool version 0.5.26 and the introduction of the rlibtool symlink (the equivalent of slibtool --heuristics), slibtool may now be told to automatically detect its desired operation mode (share-only, static-only, or both) by way of parsing the generated libtool script which it replaces.
2018-10-30 04:01:00 +01:00
cd obj_binutils && $(MAKE) MAKE="$(MAKE) $(LIBTOOL_ARG)" all
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
touch $@
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
obj_gcc/.lc_configured: | obj_gcc src_gcc
cd obj_gcc && ../src_gcc/configure $(FULL_GCC_CONFIG)
touch $@
remove explicit target definitions for gmp, mpfr, and mpc. Originally added in commit 40d6414f28d4698ff6245f9d07bedfe799953d50, the purpose of the above target definitions was to allow using the static-only symlink variant of slibtool (i.e. slibtool-static) in those build steps which required it. Given slibtool's newly added ability to auto-detect its desired operation mode (shared-only, static-only, or both), as well as the integration of rlibtool support in mcm, the aforementioned explicit target definitions are no longer needed.
2018-10-31 03:35:07 +01:00
obj_gcc/gcc/.lc_built: | obj_gcc/.lc_configured
support using an alternate libtool utility, such as slibtool.
2018-02-28 03:56:48 +01:00
cd obj_gcc && $(MAKE) MAKE="$(MAKE) $(LIBTOOL_ARG)" all-gcc
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
touch $@
Move sysroot-specific dependencies to !NATIVE section
2016-12-03 10:58:12 +01:00
obj_musl/.lc_configured: | obj_musl src_musl
litecross: add support for cross-compiling a native toolchain experimental feature. activated by setting NATIVE make var. cross-compiler for the host/target system must already be installed at a location in PATH.
2016-05-06 05:00:35 +02:00
cd obj_musl && ../src_musl/configure $(FULL_MUSL_CONFIG)
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
touch $@
obj_sysroot/.lc_headers: | obj_musl/.lc_configured obj_sysroot
Use $(CURDIR) instead of $(PWD) in Makefile Some shells (in particular ksh) don't export PWD by default, so it doesn't end up as a make variable.
2016-12-02 08:14:01 +01:00
cd obj_musl && $(MAKE) DESTDIR=$(CURDIR)/obj_sysroot install-headers
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
touch $@
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
obj_gcc/$(TARGET)/libgcc/libgcc.a: | obj_sysroot/.lc_headers
support using an alternate libtool utility, such as slibtool.
2018-02-28 03:56:48 +01:00
cd obj_gcc && $(MAKE) MAKE="$(MAKE) enable_shared=no $(LIBTOOL_ARG)" all-target-libgcc
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
litecross: add support for cross-compiling a native toolchain experimental feature. activated by setting NATIVE make var. cross-compiler for the host/target system must already be installed at a location in PATH.
2016-05-06 05:00:35 +02:00
obj_musl/.lc_built: | obj_musl/.lc_configured
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
cd obj_musl && $(MAKE) $(MUSL_VARS)
touch $@
obj_sysroot/.lc_libs: | obj_musl/.lc_built
Use $(CURDIR) instead of $(PWD) in Makefile Some shells (in particular ksh) don't export PWD by default, so it doesn't end up as a make variable.
2016-12-02 08:14:01 +01:00
cd obj_musl && $(MAKE) $(MUSL_VARS) DESTDIR=$(CURDIR)/obj_sysroot install
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
touch $@
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
obj_gcc/.lc_built: | obj_gcc/.lc_configured obj_gcc/gcc/.lc_built
support using an alternate libtool utility, such as slibtool.
2018-02-28 03:56:48 +01:00
cd obj_gcc && $(MAKE) MAKE="$(MAKE) $(LIBTOOL_ARG)"
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
touch $@
install-musl: | obj_musl/.lc_built
litecross: add support for cross-compiling a native toolchain experimental feature. activated by setting NATIVE make var. cross-compiler for the host/target system must already be installed at a location in PATH.
2016-05-06 05:00:35 +02:00
cd obj_musl && $(MAKE) $(MUSL_VARS) DESTDIR=$(DESTDIR)$(OUTPUT)$(SYSROOT) install
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
install-binutils: | obj_binutils/.lc_built
slibtool support: remove the LIBTOOL_STATIC_ARG var (no longer needed). Beginning with slibtool version 0.5.26 and the introduction of the rlibtool symlink (the equivalent of slibtool --heuristics), slibtool may now be told to automatically detect its desired operation mode (share-only, static-only, or both) by way of parsing the generated libtool script which it replaces.
2018-10-30 04:01:00 +01:00
cd obj_binutils && $(MAKE) MAKE="$(MAKE) $(LIBTOOL_ARG)" DESTDIR=$(DESTDIR)$(OUTPUT) install
litecross: separate binutils and gcc build trees putting them together in one tree only works if they're "sufficiently close" in version, due to each needing (approximately) its own version of libiberty and possibly the top-level configure infrastructure. eventually, I want to stage the installs of binutils and gcc under the build directory, so that the new binutils can be used from their staged install paths. leave that refactorization for later; for now, give gcc the binutils it needs directly out of the binutils build directories.
2018-02-26 22:02:16 +01:00
install-gcc: | obj_gcc/.lc_built
support using an alternate libtool utility, such as slibtool.
2018-02-28 03:56:48 +01:00
cd obj_gcc && $(MAKE) MAKE="$(MAKE) $(LIBTOOL_ARG)" DESTDIR=$(DESTDIR)$(OUTPUT) install
litecross: create $(TARGET)-cc symlink for installed compiler in case the user does not want to write the 'g' when invoking 'gcc'.
2016-05-14 05:09:41 +02:00
ln -sf $(TARGET)-gcc $(DESTDIR)$(OUTPUT)/bin/$(TARGET)-cc
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
add support for installation of linux kernel headers this feature is still experimental and requires manually setting a LINUX_ARCH make variable matching the target. automatic mapping will be added later. if LINUX_ARCH is not set, header installation is skipped.
2016-05-14 06:14:52 +02:00
ifneq ($(LINUX_SRCDIR),)
litecross: automatically determine LINUX_ARCH for kernel headers
2016-05-14 07:23:25 +02:00
TARGET_ARCH = $(firstword $(subst -, ,$(TARGET)))
TARGET_ARCH_MANGLED = $(patsubst i%86,x86,$(patsubst aarch64%,arm64%,$(TARGET_ARCH)))
LINUX_ARCH_LIST = $(sort $(notdir $(wildcard $(LINUX_SRCDIR)/arch/*)))
Fix LINUX_ARCH for aarch64-* TARGET 'aarch64' is converted to 'arm64' in the TARGET_ARCH_MANGLED assignment, but then LINUX_ARCH is set the first to the first linux arch which appears in TARGET_ARCH_MANGLED. Since 'arm' is a substring of 'arm64' and appears ahead of 'arm64' in sorted order, it gets chosen incorrectly. To fix this, use 'lastword' instead of 'firstword'. This should work for all current linux architectures, but is still not perfect in the theoretical case where the substring match is not rooted at the beginning of TARGET_ARCH_MANGLED. So, also replace 'findstring' with an 'if' and 'filter'.
2017-08-20 22:30:33 +02:00
LINUX_ARCH = $(lastword $(foreach a,$(LINUX_ARCH_LIST),$(if $(filter $(a)%,$(TARGET_ARCH_MANGLED)),$(a))))
add support for installation of linux kernel headers this feature is still experimental and requires manually setting a LINUX_ARCH make variable matching the target. automatic mapping will be added later. if LINUX_ARCH is not set, header installation is skipped.
2016-05-14 06:14:52 +02:00
ifneq ($(LINUX_ARCH),)
all: kernel-headers
install: install-kernel-headers
litecross: simplify and fix kernel header installation I didn't realize before but, using the O make variable, kernel source can do out-of-tree builds, making it safe to use a symlink rather than partial copy for the source dir. the partial copy did not work for all archs; in particular x86 was broken.
2016-05-14 09:34:36 +02:00
kernel-headers: | obj_kernel_headers/.lc_built
add support for installation of linux kernel headers this feature is still experimental and requires manually setting a LINUX_ARCH make variable matching the target. automatic mapping will be added later. if LINUX_ARCH is not set, header installation is skipped.
2016-05-14 06:14:52 +02:00
src_kernel_headers: | $(LINUX_SRCDIR)
litecross: simplify and fix kernel header installation I didn't realize before but, using the O make variable, kernel source can do out-of-tree builds, making it safe to use a symlink rather than partial copy for the source dir. the partial copy did not work for all archs; in particular x86 was broken.
2016-05-14 09:34:36 +02:00
ln -sf "$(LINUX_SRCDIR)" $@
obj_kernel_headers/.lc_built: | src_kernel_headers
Use $(CURDIR) instead of $(PWD) in Makefile Some shells (in particular ksh) don't export PWD by default, so it doesn't end up as a make variable.
2016-12-02 08:14:01 +01:00
mkdir -p $(CURDIR)/obj_kernel_headers/staged
cd src_kernel_headers && $(MAKE) ARCH=$(LINUX_ARCH) O=$(CURDIR)/obj_kernel_headers INSTALL_HDR_PATH=$(CURDIR)/obj_kernel_headers/staged headers_install
Prune .install and ..install.cmd files from kernel headers These files aren't useful, especially for a toolchain meant to be relocated, because they contain references to the staging directory and source paths.
2016-12-03 08:56:06 +01:00
find obj_kernel_headers/staged/include '(' -name .install -o -name ..install.cmd ')' -exec rm {} +
litecross: simplify and fix kernel header installation I didn't realize before but, using the O make variable, kernel source can do out-of-tree builds, making it safe to use a symlink rather than partial copy for the source dir. the partial copy did not work for all archs; in particular x86 was broken.
2016-05-14 09:34:36 +02:00
touch $@
install-kernel-headers: | obj_kernel_headers/.lc_built
add support for installation of linux kernel headers this feature is still experimental and requires manually setting a LINUX_ARCH make variable matching the target. automatic mapping will be added later. if LINUX_ARCH is not set, header installation is skipped.
2016-05-14 06:14:52 +02:00
mkdir -p $(DESTDIR)$(OUTPUT)$(SYSROOT)/include
litecross: simplify and fix kernel header installation I didn't realize before but, using the O make variable, kernel source can do out-of-tree builds, making it safe to use a symlink rather than partial copy for the source dir. the partial copy did not work for all archs; in particular x86 was broken.
2016-05-14 09:34:36 +02:00
cp -R obj_kernel_headers/staged/include/* $(DESTDIR)$(OUTPUT)$(SYSROOT)/include
add support for installation of linux kernel headers this feature is still experimental and requires manually setting a LINUX_ARCH make variable matching the target. automatic mapping will be added later. if LINUX_ARCH is not set, header installation is skipped.
2016-05-14 06:14:52 +02:00
endif
endif
overhaul build process with litecross, next-gen top-level makefile
2016-05-01 07:36:28 +02:00
endif
clean:
rm -rf src_* obj_*