|
|
|
|
package=native_cctools
|
|
|
|
|
$(package)_version=55562e4073dea0fbfd0b20e0bf69ffe6390c7f97
|
|
|
|
|
$(package)_download_path=https://github.com/tpoechtrager/cctools-port/archive
|
depends: major upgrade to darwin toolchain
tl;dr: Update to the newer stable toolchain and SDK for OSX without giving up
any backwards compatibility. We can move to clang 3.5 as a next step which
allows use to use libc++ and the 10.10 sdk, but we'll need to find a build that
works in gitian/travis first.
Switch to a new, better maintained fork of cctools:
https://github.com/tpoechtrager/cctools-port
I've forked this and will be working on it some as well:
https://github.com/theuni/cctools-port
This brings in:
cctools v862
ld64: v241.9
It also fixes 64bit builds, so there's no longer any need to use a 32bit clang.
Since clang is no longer tied to an old/crusty 32bit build, clang has been
upgraded to 3.3. Unfortunately, there's a bug in 3.4 that breaks builds. 3.5
works fine, but there are no binary builds compatible with precise, which is
currently used for gitian and travis. We could always build our own if
necessary.
After updating to stable clang/linker/cctools, it's possible to use a more
recent SDK. The current SDK (10.7) through the most recent 10.10 have all been
built/tested successfully, both with and without 10.6 compatibility. However,
10.10 requires clang 3.5.
SDKs >= 10.9 use libc++ rather than libstdc++. This is verified working as well.
10 years ago
|
|
|
$(package)_file_name=$($(package)_version).tar.gz
|
|
|
|
|
$(package)_sha256_hash=e51995a843533a3dac155dd0c71362dd471597a2d23f13dff194c6285362f875
|
depends: major upgrade to darwin toolchain
tl;dr: Update to the newer stable toolchain and SDK for OSX without giving up
any backwards compatibility. We can move to clang 3.5 as a next step which
allows use to use libc++ and the 10.10 sdk, but we'll need to find a build that
works in gitian/travis first.
Switch to a new, better maintained fork of cctools:
https://github.com/tpoechtrager/cctools-port
I've forked this and will be working on it some as well:
https://github.com/theuni/cctools-port
This brings in:
cctools v862
ld64: v241.9
It also fixes 64bit builds, so there's no longer any need to use a 32bit clang.
Since clang is no longer tied to an old/crusty 32bit build, clang has been
upgraded to 3.3. Unfortunately, there's a bug in 3.4 that breaks builds. 3.5
works fine, but there are no binary builds compatible with precise, which is
currently used for gitian and travis. We could always build our own if
necessary.
After updating to stable clang/linker/cctools, it's possible to use a more
recent SDK. The current SDK (10.7) through the most recent 10.10 have all been
built/tested successfully, both with and without 10.6 compatibility. However,
10.10 requires clang 3.5.
SDKs >= 10.9 use libc++ rather than libstdc++. This is verified working as well.
10 years ago
|
|
|
$(package)_build_subdir=cctools
|
|
|
|
|
$(package)_patches=ld64_disable_threading.patch
|
|
|
|
|
|
|
|
|
|
ifeq ($(strip $(FORCE_USE_SYSTEM_CLANG)),)
|
|
|
|
|
$(package)_clang_version=8.0.0
|
|
|
|
|
$(package)_clang_download_path=https://releases.llvm.org/$($(package)_clang_version)
|
|
|
|
|
$(package)_clang_download_file=clang+llvm-$($(package)_clang_version)-x86_64-linux-gnu-ubuntu-14.04.tar.xz
|
|
|
|
|
$(package)_clang_file_name=clang-llvm-$($(package)_clang_version)-x86_64-linux-gnu-ubuntu-14.04.tar.xz
|
|
|
|
|
$(package)_clang_sha256_hash=9ef854b71949f825362a119bf2597f744836cb571131ae6b721cd102ffea8cd0
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
$(package)_libtapi_version=3efb201881e7a76a21e0554906cf306432539cef
|
|
|
|
|
$(package)_libtapi_download_path=https://github.com/tpoechtrager/apple-libtapi/archive
|
|
|
|
|
$(package)_libtapi_download_file=$($(package)_libtapi_version).tar.gz
|
|
|
|
|
$(package)_libtapi_file_name=$($(package)_libtapi_version).tar.gz
|
|
|
|
|
$(package)_libtapi_sha256_hash=380c1ca37cfa04a8699d0887a8d3ee1ad27f3d08baba78887c73b09485c0fbd3
|
|
|
|
|
|
|
|
|
|
$(package)_extra_sources=$($(package)_libtapi_file_name)
|
|
|
|
|
ifeq ($(strip $(FORCE_USE_SYSTEM_CLANG)),)
|
|
|
|
|
$(package)_extra_sources += $($(package)_clang_file_name)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(strip $(FORCE_USE_SYSTEM_CLANG)),)
|
|
|
|
|
define $(package)_fetch_cmds
|
|
|
|
|
$(call fetch_file,$(package),$($(package)_download_path),$($(package)_download_file),$($(package)_file_name),$($(package)_sha256_hash)) && \
|
|
|
|
|
$(call fetch_file,$(package),$($(package)_clang_download_path),$($(package)_clang_download_file),$($(package)_clang_file_name),$($(package)_clang_sha256_hash)) && \
|
|
|
|
|
$(call fetch_file,$(package),$($(package)_libtapi_download_path),$($(package)_libtapi_download_file),$($(package)_libtapi_file_name),$($(package)_libtapi_sha256_hash))
|
|
|
|
|
endef
|
|
|
|
|
else
|
|
|
|
|
define $(package)_fetch_cmds
|
|
|
|
|
$(call fetch_file,$(package),$($(package)_download_path),$($(package)_download_file),$($(package)_file_name),$($(package)_sha256_hash)) && \
|
|
|
|
|
$(call fetch_file,$(package),$($(package)_libtapi_download_path),$($(package)_libtapi_download_file),$($(package)_libtapi_file_name),$($(package)_libtapi_sha256_hash))
|
|
|
|
|
endef
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(strip $(FORCE_USE_SYSTEM_CLANG)),)
|
|
|
|
|
define $(package)_extract_cmds
|
|
|
|
|
mkdir -p $($(package)_extract_dir) && \
|
|
|
|
|
echo "$($(package)_sha256_hash) $($(package)_source)" > $($(package)_extract_dir)/.$($(package)_file_name).hash && \
|
|
|
|
|
echo "$($(package)_clang_sha256_hash) $($(package)_source_dir)/$($(package)_clang_file_name)" >> $($(package)_extract_dir)/.$($(package)_file_name).hash && \
|
|
|
|
|
echo "$($(package)_libtapi_sha256_hash) $($(package)_source_dir)/$($(package)_libtapi_file_name)" >> $($(package)_extract_dir)/.$($(package)_file_name).hash && \
|
|
|
|
|
$(build_SHA256SUM) -c $($(package)_extract_dir)/.$($(package)_file_name).hash && \
|
|
|
|
|
mkdir -p toolchain/bin toolchain/lib/clang/$($(package)_clang_version)/include && \
|
|
|
|
|
mkdir -p libtapi && \
|
|
|
|
|
tar --no-same-owner --strip-components=1 -C libtapi -xf $($(package)_source_dir)/$($(package)_libtapi_file_name) && \
|
|
|
|
|
tar --no-same-owner --strip-components=1 -C toolchain -xf $($(package)_source_dir)/$($(package)_clang_file_name) && \
|
|
|
|
|
rm -f toolchain/lib/libc++abi.so* && \
|
|
|
|
|
tar --no-same-owner --strip-components=1 -xf $($(package)_source)
|
depends: major upgrade to darwin toolchain
tl;dr: Update to the newer stable toolchain and SDK for OSX without giving up
any backwards compatibility. We can move to clang 3.5 as a next step which
allows use to use libc++ and the 10.10 sdk, but we'll need to find a build that
works in gitian/travis first.
Switch to a new, better maintained fork of cctools:
https://github.com/tpoechtrager/cctools-port
I've forked this and will be working on it some as well:
https://github.com/theuni/cctools-port
This brings in:
cctools v862
ld64: v241.9
It also fixes 64bit builds, so there's no longer any need to use a 32bit clang.
Since clang is no longer tied to an old/crusty 32bit build, clang has been
upgraded to 3.3. Unfortunately, there's a bug in 3.4 that breaks builds. 3.5
works fine, but there are no binary builds compatible with precise, which is
currently used for gitian and travis. We could always build our own if
necessary.
After updating to stable clang/linker/cctools, it's possible to use a more
recent SDK. The current SDK (10.7) through the most recent 10.10 have all been
built/tested successfully, both with and without 10.6 compatibility. However,
10.10 requires clang 3.5.
SDKs >= 10.9 use libc++ rather than libstdc++. This is verified working as well.
10 years ago
|
|
|
endef
|
|
|
|
|
else
|
|
|
|
|
define $(package)_extract_cmds
|
|
|
|
|
mkdir -p $($(package)_extract_dir) && \
|
|
|
|
|
echo "$($(package)_sha256_hash) $($(package)_source)" > $($(package)_extract_dir)/.$($(package)_file_name).hash && \
|
|
|
|
|
echo "$($(package)_libtapi_sha256_hash) $($(package)_source_dir)/$($(package)_libtapi_file_name)" >> $($(package)_extract_dir)/.$($(package)_file_name).hash && \
|
|
|
|
|
$(build_SHA256SUM) -c $($(package)_extract_dir)/.$($(package)_file_name).hash && \
|
|
|
|
|
mkdir -p libtapi && \
|
|
|
|
|
tar --no-same-owner --strip-components=1 -C libtapi -xf $($(package)_source_dir)/$($(package)_libtapi_file_name) && \
|
|
|
|
|
tar --no-same-owner --strip-components=1 -xf $($(package)_source)
|
|
|
|
|
endef
|
|
|
|
|
endif
|
depends: major upgrade to darwin toolchain
tl;dr: Update to the newer stable toolchain and SDK for OSX without giving up
any backwards compatibility. We can move to clang 3.5 as a next step which
allows use to use libc++ and the 10.10 sdk, but we'll need to find a build that
works in gitian/travis first.
Switch to a new, better maintained fork of cctools:
https://github.com/tpoechtrager/cctools-port
I've forked this and will be working on it some as well:
https://github.com/theuni/cctools-port
This brings in:
cctools v862
ld64: v241.9
It also fixes 64bit builds, so there's no longer any need to use a 32bit clang.
Since clang is no longer tied to an old/crusty 32bit build, clang has been
upgraded to 3.3. Unfortunately, there's a bug in 3.4 that breaks builds. 3.5
works fine, but there are no binary builds compatible with precise, which is
currently used for gitian and travis. We could always build our own if
necessary.
After updating to stable clang/linker/cctools, it's possible to use a more
recent SDK. The current SDK (10.7) through the most recent 10.10 have all been
built/tested successfully, both with and without 10.6 compatibility. However,
10.10 requires clang 3.5.
SDKs >= 10.9 use libc++ rather than libstdc++. This is verified working as well.
10 years ago
|
|
|
|
|
|
|
|
define $(package)_set_vars
|
|
|
|
|
$(package)_config_opts=--target=$(host) --with-libtapi=$($(package)_extract_dir)
|
|
|
|
|
$(package)_ldflags+=-Wl,-rpath=\\$$$$$$$$\$$$$$$$$ORIGIN/../lib
|
|
|
|
|
ifeq ($(strip $(FORCE_USE_SYSTEM_CLANG)),)
|
|
|
|
|
$(package)_config_opts+=--enable-lto-support --with-llvm-config=$($(package)_extract_dir)/toolchain/bin/llvm-config
|
|
|
|
|
$(package)_cc=$($(package)_extract_dir)/toolchain/bin/clang
|
|
|
|
|
$(package)_cxx=$($(package)_extract_dir)/toolchain/bin/clang++
|
|
|
|
|
else
|
|
|
|
|
$(package)_cc=clang
|
|
|
|
|
$(package)_cxx=clang++
|
|
|
|
|
endif
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
define $(package)_preprocess_cmds
|
|
|
|
|
CC=$($(package)_cc) CXX=$($(package)_cxx) INSTALLPREFIX=$($(package)_extract_dir) ./libtapi/build.sh && \
|
|
|
|
|
CC=$($(package)_cc) CXX=$($(package)_cxx) INSTALLPREFIX=$($(package)_extract_dir) ./libtapi/install.sh && \
|
|
|
|
|
patch -p1 < $($(package)_patch_dir)/ld64_disable_threading.patch
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
define $(package)_config_cmds
|
|
|
|
|
$($(package)_autoconf)
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
define $(package)_build_cmds
|
|
|
|
|
$(MAKE)
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
ifeq ($(strip $(FORCE_USE_SYSTEM_CLANG)),)
|
|
|
|
|
define $(package)_stage_cmds
|
|
|
|
|
$(MAKE) DESTDIR=$($(package)_staging_dir) install && \
|
|
|
|
|
mkdir -p $($(package)_staging_prefix_dir)/lib/ && \
|
|
|
|
|
cd $($(package)_extract_dir) && \
|
|
|
|
|
cp lib/libtapi.so.6 $($(package)_staging_prefix_dir)/lib/ && \
|
depends: major upgrade to darwin toolchain
tl;dr: Update to the newer stable toolchain and SDK for OSX without giving up
any backwards compatibility. We can move to clang 3.5 as a next step which
allows use to use libc++ and the 10.10 sdk, but we'll need to find a build that
works in gitian/travis first.
Switch to a new, better maintained fork of cctools:
https://github.com/tpoechtrager/cctools-port
I've forked this and will be working on it some as well:
https://github.com/theuni/cctools-port
This brings in:
cctools v862
ld64: v241.9
It also fixes 64bit builds, so there's no longer any need to use a 32bit clang.
Since clang is no longer tied to an old/crusty 32bit build, clang has been
upgraded to 3.3. Unfortunately, there's a bug in 3.4 that breaks builds. 3.5
works fine, but there are no binary builds compatible with precise, which is
currently used for gitian and travis. We could always build our own if
necessary.
After updating to stable clang/linker/cctools, it's possible to use a more
recent SDK. The current SDK (10.7) through the most recent 10.10 have all been
built/tested successfully, both with and without 10.6 compatibility. However,
10.10 requires clang 3.5.
SDKs >= 10.9 use libc++ rather than libstdc++. This is verified working as well.
10 years ago
|
|
|
cd $($(package)_extract_dir)/toolchain && \
|
|
|
|
|
mkdir -p $($(package)_staging_prefix_dir)/lib/clang/$($(package)_clang_version)/include && \
|
|
|
|
|
mkdir -p $($(package)_staging_prefix_dir)/bin $($(package)_staging_prefix_dir)/include && \
|
|
|
|
|
cp bin/clang $($(package)_staging_prefix_dir)/bin/ &&\
|
|
|
|
|
cp -P bin/clang++ $($(package)_staging_prefix_dir)/bin/ &&\
|
|
|
|
|
cp lib/libLTO.so $($(package)_staging_prefix_dir)/lib/ && \
|
depends: major upgrade to darwin toolchain
tl;dr: Update to the newer stable toolchain and SDK for OSX without giving up
any backwards compatibility. We can move to clang 3.5 as a next step which
allows use to use libc++ and the 10.10 sdk, but we'll need to find a build that
works in gitian/travis first.
Switch to a new, better maintained fork of cctools:
https://github.com/tpoechtrager/cctools-port
I've forked this and will be working on it some as well:
https://github.com/theuni/cctools-port
This brings in:
cctools v862
ld64: v241.9
It also fixes 64bit builds, so there's no longer any need to use a 32bit clang.
Since clang is no longer tied to an old/crusty 32bit build, clang has been
upgraded to 3.3. Unfortunately, there's a bug in 3.4 that breaks builds. 3.5
works fine, but there are no binary builds compatible with precise, which is
currently used for gitian and travis. We could always build our own if
necessary.
After updating to stable clang/linker/cctools, it's possible to use a more
recent SDK. The current SDK (10.7) through the most recent 10.10 have all been
built/tested successfully, both with and without 10.6 compatibility. However,
10.10 requires clang 3.5.
SDKs >= 10.9 use libc++ rather than libstdc++. This is verified working as well.
10 years ago
|
|
|
cp -rf lib/clang/$($(package)_clang_version)/include/* $($(package)_staging_prefix_dir)/lib/clang/$($(package)_clang_version)/include/ && \
|
|
|
|
|
cp bin/dsymutil $($(package)_staging_prefix_dir)/bin/$(host)-dsymutil
|
|
|
|
|
endef
|
|
|
|
|
else
|
|
|
|
|
define $(package)_stage_cmds
|
|
|
|
|
$(MAKE) DESTDIR=$($(package)_staging_dir) install && \
|
|
|
|
|
mkdir -p $($(package)_staging_prefix_dir)/lib/ && \
|
|
|
|
|
cd $($(package)_extract_dir) && \
|
|
|
|
|
cp lib/libtapi.so.6 $($(package)_staging_prefix_dir)/lib/
|
|
|
|
|
endef
|
|
|
|
|
endif
|
