mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
12ccff99bf
rust/mk/rt.mk

700 lines
20 KiB
Makefile
Raw Normal View History

Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
# Copyright 2014 The Rust Project Developers. See the COPYRIGHT
# file at the top-level directory of this distribution and at
# http://rust-lang.org/COPYRIGHT.
virtualize the runtime per target triple.
2011-11-01 18:50:47 -05:00
#
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
# Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
# http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
# <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
# option. This file may not be copied, modified, or distributed
# except according to those terms.
################################################################################
# Native libraries built as part of the rust build process
virtualize the runtime per target triple.
2011-11-01 18:50:47 -05:00
#
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
# This portion of the rust build system is meant to keep track of native
# dependencies and how to build them. It is currently required that all native
# dependencies are built as static libraries, as slinging around dynamic
# libraries isn't exactly the most fun thing to do.
virtualize the runtime per target triple.
2011-11-01 18:50:47 -05:00
#
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
# This section should need minimal modification to add new libraries. The
# relevant variables are:
virtualize the runtime per target triple.
2011-11-01 18:50:47 -05:00
#
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
# NATIVE_LIBS
# This is a list of all native libraries which are built as part of the
# build process. It will build all libraries into RT_OUTPUT_DIR with the
# appropriate name of static library as dictated by the target platform
#
# NATIVE_DEPS_<lib>
# This is a list of files relative to the src/rt directory which are
# needed to build the native library. Each file will be compiled to an
# object file, and then all the object files will be assembled into an
# archive (static library). The list contains files of any extension
#
# If adding a new library, you should update the NATIVE_LIBS list, and then list
# the required files below it. The list of required files is a list of files
# that's per-target so you're allowed to conditionally add files based on the
# target.
################################################################################
std: Remove rust_builtin C support library All these definitions can now be written in Rust, so do so!
2015-12-02 12:31:29 -06:00
NATIVE_LIBS := hoedown miniz rust_test_helpers
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
# $(1) is the target triple
define NATIVE_LIBRARIES
rustdoc: Migrate from sundown to hoedown This primary fix brought on by this upgrade is the proper matching of the ``` and ~~~ doc blocks. This also moves hoedown to a git submodule rather than a bundled repository. Additionally, hoedown is stricter about code blocks, so this ended up fixing a lot of invalid code blocks (ending with " ```" instead of "```", or ending with "~~~~" instead of "~~~"). Closes #12776
2014-05-02 19:56:35 -05:00
NATIVE_DEPS_hoedown_$(1) := hoedown/src/autolink.c \
hoedown/src/buffer.c \
hoedown/src/document.c \
hoedown/src/escape.c \
hoedown/src/html.c \
hoedown/src/html_blocks.c \
hoedown/src/html_smartypants.c \
hoedown/src/stack.c \
hoedown/src/version.c
Move extra::flate to libflate This is hopefully the beginning of the long-awaited dissolution of libextra. Using the newly created build infrastructure for building libraries, I decided to move the first module out of libextra. While not being a particularly meaty module in and of itself, the flate module is required by rustc and additionally has a native C dependency. I was able to very easily split out the C dependency from rustrt, update librustc, and magically everything gets installed to the right locations and built automatically. This is meant to be a proof-of-concept commit to how easy it is to remove modules from libextra now. I didn't put any effort into modernizing the interface of libflate or updating it other than to remove the one glob import it had.
2014-01-24 23:00:31 -06:00
NATIVE_DEPS_miniz_$(1) = miniz.c
mk: Move rust_test_helpers out of libstd There's no need to distribute these ABI helpers for tests with the standard rust distribution they're only needed for our tests. Closes #2665
2014-06-05 13:08:43 -05:00
NATIVE_DEPS_rust_test_helpers_$(1) := rust_test_helpers.c
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
################################################################################
# You shouldn't find it that necessary to edit anything below this line.
################################################################################
# While we're defining the native libraries for each target, we define some
# common rules used to build files for various targets.
virtualize the runtime per target triple.
2011-11-01 18:50:47 -05:00
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
RT_OUTPUT_DIR_$(1) := $(1)/rt
Remove VPATH usage in Makefiles This is just messing up all the doc dependencies because of such similar directory names and file names. Closes #11422
2014-01-28 16:14:51 -06:00
$$(RT_OUTPUT_DIR_$(1))/%.o: $(S)src/rt/%.c $$(MKFILE_DEPS)
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
@mkdir -p $$(@D)
@$$(call E, compile: $$@)
$$(Q)$$(call CFG_COMPILE_C_$(1), $$@, \
mk: Add build system support for cl.exe We have a number of support C/C++ files in Rust that we link into the standard library and other various locations, and these all need to be built with cl.exe instead of gcc.exe when targeting MSVC. This commit adds helper macros for this functionality to use different sets of programs/flags/invocations on MSVC than on GNU-like platforms.
2015-05-11 16:07:42 -05:00
$$(call CFG_CC_INCLUDE_$(1),$$(S)src/rt/hoedown/src) \
$$(call CFG_CC_INCLUDE_$(1),$$(S)src/rt) \
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
$$(RUNTIME_CFLAGS_$(1))) $$<
Remove VPATH usage in Makefiles This is just messing up all the doc dependencies because of such similar directory names and file names. Closes #11422
2014-01-28 16:14:51 -06:00
$$(RT_OUTPUT_DIR_$(1))/%.o: $(S)src/rt/%.S $$(MKFILE_DEPS) \
$$(LLVM_CONFIG_$$(CFG_BUILD))
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
@mkdir -p $$(@D)
@$$(call E, compile: $$@)
$$(Q)$$(call CFG_ASSEMBLE_$(1),$$@,$$<)
mk: Add support for i686-pc-windows-msvc This commit modifies the configure script and our makefiles to support building 32-bit MSVC targets. The MSVC toolchain is now parameterized over whether it can produce a 32-bit or 64-bit binary. The configure script was updated to export more variables at configure time, and the makefiles were rejiggered to selectively reexport the relevant environment variables for the applicable targets they're going to run for.
2015-06-25 17:30:00 -05:00
# On MSVC targets the compiler's default include path (e.g. where to find system
# headers) is specified by the INCLUDE environment variable. This may not be set
# so the ./configure script scraped the relevant values and this is the location
# that we put them into cl.exe's environment.
ifeq ($$(findstring msvc,$(1)),msvc)
$$(RT_OUTPUT_DIR_$(1))/%.o: \
export INCLUDE := $$(CFG_MSVC_INCLUDE_PATH_$$(HOST_$(1)))
$(1)/rustllvm/%.o: \
export INCLUDE := $$(CFG_MSVC_INCLUDE_PATH_$$(HOST_$(1)))
endif
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
endef
$(foreach target,$(CFG_TARGET),$(eval $(call NATIVE_LIBRARIES,$(target))))
# A macro for devining how to build third party libraries listed above (based
# on their dependencies).
#
# $(1) is the target
# $(2) is the lib name
define THIRD_PARTY_LIB
OBJS_$(2)_$(1) := $$(NATIVE_DEPS_$(2)_$(1):%=$$(RT_OUTPUT_DIR_$(1))/%)
OBJS_$(2)_$(1) := $$(OBJS_$(2)_$(1):.c=.o)
OBJS_$(2)_$(1) := $$(OBJS_$(2)_$(1):.cpp=.o)
OBJS_$(2)_$(1) := $$(OBJS_$(2)_$(1):.S=.o)
NATIVE_$(2)_$(1) := $$(call CFG_STATIC_LIB_NAME_$(1),$(2))
$$(RT_OUTPUT_DIR_$(1))/$$(NATIVE_$(2)_$(1)): $$(OBJS_$(2)_$(1))
@$$(call E, link: $$@)
mk: Add build system support for cl.exe We have a number of support C/C++ files in Rust that we link into the standard library and other various locations, and these all need to be built with cl.exe instead of gcc.exe when targeting MSVC. This commit adds helper macros for this functionality to use different sets of programs/flags/invocations on MSVC than on GNU-like platforms.
2015-05-11 16:07:42 -05:00
$$(Q)$$(call CFG_CREATE_ARCHIVE_$(1),$$@) $$^
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
endef
Revert "mk: fix some undefined variable warnings" This reverts commit d03712977d7c913044f2b863269c4491d7fa7c36.
2016-02-02 01:27:04 -06:00
$(foreach target,$(CFG_TARGET), \
$(eval $(call RUNTIME_RULES,$(target))))
mk: Remove extra whitespace before line continuation backslashes
2014-07-22 23:37:05 -05:00
$(foreach lib,$(NATIVE_LIBS), \
$(foreach target,$(CFG_TARGET), \
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
$(eval $(call THIRD_PARTY_LIB,$(target),$(lib)))))
Disable some advanced (post glibc-2.3) libuv features when building snaps.
2012-03-26 17:54:22 -05:00
Refactor the build system for easily adding crates Before this patch, if you wanted to add a crate to the build system you had to change about 100 lines across 8 separate makefiles. This is highly error prone and opaque to all but a few. This refactoring is targeted at consolidating this effort so adding a new crate adds one line in one file in a way that everyone can understand it.
2014-01-24 21:27:22 -06:00
################################################################################
# Building third-party targets with external build systems
#
add back jemalloc to the tree This adds a `std::rt::heap` module with a nice allocator API. It's a step towards fixing #13094 and is a starting point for working on a generic allocator trait. The revision used for the jemalloc submodule is the stable 3.6.0 release. Closes #11807
2014-04-25 01:19:34 -05:00
# This location is meant for dependencies which have external build systems. It
# is still assumed that the output of each of these steps is a static library
# in the correct location.
################################################################################
Build libuv/jemalloc only once (not per stage) Reorganize the makefiles to stop building these once per stage because there's no need to do this at all. Closes #7002
2013-10-08 11:20:17 -05:00
define DEF_THIRD_PARTY_TARGETS
# $(1) is the target triple
std: Update jemalloc version It's been awhile since we last updated jemalloc, and there's likely some bugs that have been fixed since the last version we're using, so let's try to update again.
2015-12-17 01:06:00 -06:00
ifeq ($$(CFG_WINDOWSY_$(1)),1)
# A bit of history here, this used to be --enable-lazy-lock added in #14006
# which was filed with jemalloc in jemalloc/jemalloc#83 which was also
# reported to MinGW: http://sourceforge.net/p/mingw-w64/bugs/395/
add back jemalloc to the tree This adds a `std::rt::heap` module with a nice allocator API. It's a step towards fixing #13094 and is a starting point for working on a generic allocator trait. The revision used for the jemalloc submodule is the stable 3.6.0 release. Closes #11807
2014-04-25 01:19:34 -05:00
#
std: Update jemalloc version It's been awhile since we last updated jemalloc, and there's likely some bugs that have been fixed since the last version we're using, so let's try to update again.
2015-12-17 01:06:00 -06:00
# When updating jemalloc to 4.0, however, it was found that binaries would
# exit with the status code STATUS_RESOURCE_NOT_OWNED indicating that a thread
# was unlocking a mutex it never locked. Disabling this "lazy lock" option
# seems to fix the issue, but it was enabled by default for MinGW targets in
# 13473c7 for jemalloc.
#
# As a result of all that, force disabling lazy lock on Windows, and after
# reading some code it at least *appears* that the initialization of mutexes
# is otherwise ok in jemalloc, so shouldn't cause problems hopefully...
#
# tl;dr: make windows behave like other platforms by disabling lazy locking,
# but requires passing an option due to a historical default with
# jemalloc.
JEMALLOC_ARGS_$(1) := --disable-lazy-lock
Platform configuration FIXME: avoid using Xcode build and switch to a patched libuv
2014-05-05 02:05:11 -05:00
else ifeq ($(OSTYPE_$(1)), apple-ios)
JEMALLOC_ARGS_$(1) := --disable-tls
Remove duplicated configuration for android
2015-02-02 22:42:05 -06:00
else ifeq ($(findstring android, $(OSTYPE_$(1))), android)
std: Stop prefixing jemalloc symbols Now that we properly only link in jemalloc when building executables, we have far less to worry about in terms of polluting the global namespace with the `free` and `malloc` symbols on Linux. This commit will primarily allow LLVM to use jemalloc so the compiler will only be using one allocator overall. Locally this took compile time for libsyntax from 95 seconds to 89 (a 6% improvement).
2016-02-07 00:54:35 -06:00
# We force android to have prefixed symbols because apparently replacement of
# the libc allocator doesn't quite work. When this was tested (unprefixed
# symbols), it was found that the `realpath` function in libc would allocate
# with libc malloc (not jemalloc malloc), and then the standard library would
# free with jemalloc free, causing a segfault.
#
# If the test suite passes, however, without symbol prefixes then we should be
# good to go!
JEMALLOC_ARGS_$(1) := --disable-tls --with-jemalloc-prefix=je_
Prefix jemalloc on DragonFly to prevent segfaults. Similar to commits ed015456a114ae907a36af80c06f81ea93182a24 (iOS) and e3b414d8612314e74e2b0ebde1ed5c6997d28e8d (Android)
2016-04-02 11:40:59 -05:00
else ifeq ($(findstring dragonfly, $(OSTYPE_$(1))), dragonfly)
JEMALLOC_ARGS_$(1) := --with-jemalloc-prefix=je_
mk: Allow using a locally compiled libuv.a Closes #5563
2014-06-10 12:01:21 -05:00
endif
configure: Add --enable-debug-jemalloc
2015-04-08 17:12:08 -05:00
ifdef CFG_ENABLE_DEBUG_JEMALLOC
JEMALLOC_ARGS_$(1) += --enable-debug --enable-fill
endif
add back jemalloc to the tree This adds a `std::rt::heap` module with a nice allocator API. It's a step towards fixing #13094 and is a starting point for working on a generic allocator trait. The revision used for the jemalloc submodule is the stable 3.6.0 release. Closes #11807
2014-04-25 01:19:34 -05:00
################################################################################
# jemalloc
################################################################################
ifdef CFG_ENABLE_FAST_MAKE
JEMALLOC_DEPS := $(S)/.gitmodules
else
JEMALLOC_DEPS := $(wildcard \
$(S)src/jemalloc/* \
$(S)src/jemalloc/*/* \
$(S)src/jemalloc/*/*/* \
$(S)src/jemalloc/*/*/*/*)
endif
mk: Don't depend on src/jemalloc/VERSION This file is touched during the build process and will trigger more rebuilds than necessary. Closes #17183
2014-09-14 16:42:45 -05:00
# See #17183 for details, this file is touched during the build process so we
# don't want to consider it as a dependency.
Revert "mk: fix some undefined variable warnings" This reverts commit d03712977d7c913044f2b863269c4491d7fa7c36.
2016-02-02 01:27:04 -06:00
JEMALLOC_DEPS := $(filter-out $(S)src/jemalloc/VERSION,$(JEMALLOC_DEPS))
mk: Don't depend on src/jemalloc/VERSION This file is touched during the build process and will trigger more rebuilds than necessary. Closes #17183
2014-09-14 16:42:45 -05:00
add back jemalloc to the tree This adds a `std::rt::heap` module with a nice allocator API. It's a step towards fixing #13094 and is a starting point for working on a generic allocator trait. The revision used for the jemalloc submodule is the stable 3.6.0 release. Closes #11807
2014-04-25 01:19:34 -05:00
JEMALLOC_NAME_$(1) := $$(call CFG_STATIC_LIB_NAME_$(1),jemalloc)
ifeq ($$(CFG_WINDOWSY_$(1)),1)
JEMALLOC_REAL_NAME_$(1) := $$(call CFG_STATIC_LIB_NAME_$(1),jemalloc_s)
else
JEMALLOC_REAL_NAME_$(1) := $$(call CFG_STATIC_LIB_NAME_$(1),jemalloc_pic)
endif
JEMALLOC_LIB_$(1) := $$(RT_OUTPUT_DIR_$(1))/$$(JEMALLOC_NAME_$(1))
JEMALLOC_BUILD_DIR_$(1) := $$(RT_OUTPUT_DIR_$(1))/jemalloc
mk: Allow usage of a local jemalloc install This adds a new configure option, --jemalloc-root, which will specify a location at which libjemalloc_pic.a must live. This library is then used for the build triple as the jemalloc library to link.
2014-06-07 01:52:56 -05:00
JEMALLOC_LOCAL_$(1) := $$(JEMALLOC_BUILD_DIR_$(1))/lib/$$(JEMALLOC_REAL_NAME_$(1))
add back jemalloc to the tree This adds a `std::rt::heap` module with a nice allocator API. It's a step towards fixing #13094 and is a starting point for working on a generic allocator trait. The revision used for the jemalloc submodule is the stable 3.6.0 release. Closes #11807
2014-04-25 01:19:34 -05:00
mk: Allow usage of a local jemalloc install This adds a new configure option, --jemalloc-root, which will specify a location at which libjemalloc_pic.a must live. This library is then used for the build triple as the jemalloc library to link.
2014-06-07 01:52:56 -05:00
$$(JEMALLOC_LOCAL_$(1)): $$(JEMALLOC_DEPS) $$(MKFILE_DEPS)
add back jemalloc to the tree This adds a `std::rt::heap` module with a nice allocator API. It's a step towards fixing #13094 and is a starting point for working on a generic allocator trait. The revision used for the jemalloc submodule is the stable 3.6.0 release. Closes #11807
2014-04-25 01:19:34 -05:00
@$$(call E, make: jemalloc)
cd "$$(JEMALLOC_BUILD_DIR_$(1))"; "$(S)src/jemalloc/configure" \
std: Stop prefixing jemalloc symbols Now that we properly only link in jemalloc when building executables, we have far less to worry about in terms of polluting the global namespace with the `free` and `malloc` symbols on Linux. This commit will primarily allow LLVM to use jemalloc so the compiler will only be using one allocator overall. Locally this took compile time for libsyntax from 95 seconds to 89 (a 6% improvement).
2016-02-07 00:54:35 -06:00
$$(JEMALLOC_ARGS_$(1)) $(CFG_JEMALLOC_FLAGS) \
Implement flexible target specification Removes all target-specific knowledge from rustc. Some targets have changed during this, but none of these should be very visible outside of cross-compilation. The changes make our targets more consistent. iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We used to accept any value of X greater than 1. i686 was released in 1995, and should encompass the bare minimum of what Rust supports on x86 CPUs. The only two windows targets are now i686-pc-windows-gnu and x86_64-pc-windows-gnu. The iOS target has been renamed from arm-apple-ios to arm-apple-darwin. A complete list of the targets we accept now: arm-apple-darwin arm-linux-androideabi arm-unknown-linux-gnueabi arm-unknown-linux-gnueabihf i686-apple-darwin i686-pc-windows-gnu i686-unknown-freebsd i686-unknown-linux-gnu mips-unknown-linux-gnu mipsel-unknown-linux-gnu x86_64-apple-darwin x86_64-unknown-freebsd x86_64-unknown-linux-gnu x86_64-pc-windows-gnu Closes #16093 [breaking-change]
2014-07-23 13:56:36 -05:00
--build=$$(CFG_GNU_TRIPLE_$(CFG_BUILD)) --host=$$(CFG_GNU_TRIPLE_$(1)) \
mk/rt/jemalloc: pass CFG_GCCISH_CFLAGS inside CC instead of passing CFG_CFLAGS in EXTRA_CFLAGS - CFG_CFLAGS is gone (it was previously only used by jemalloc anyhow). - CFG_JEMALLOC_CFLAGS may contain flags needed for the compiler to function (produce a binary output). - jemalloc's configure runs $(CC) without EXTRA_CFLAGS, and (without this change) will fail if any flags are required for CC to work.
2014-11-17 12:10:48 -06:00
CC="$$(CC_$(1)) $$(CFG_JEMALLOC_CFLAGS_$(1))" \
add back jemalloc to the tree This adds a `std::rt::heap` module with a nice allocator API. It's a step towards fixing #13094 and is a starting point for working on a generic allocator trait. The revision used for the jemalloc submodule is the stable 3.6.0 release. Closes #11807
2014-04-25 01:19:34 -05:00
AR="$$(AR_$(1))" \
RANLIB="$$(AR_$(1)) s" \
make sure jemalloc valgrind support is enabled This requires pointing it at the valgrind headers we carry in-tree.
2014-05-11 18:31:23 -05:00
CPPFLAGS="-I $(S)src/rt/" \
mk: Build jemalloc with -ffunction-sections It's quite possible that small programs don't use all of jemalloc, and building with -ffunction-sections and -fdata-sections allows the linker (via --gc-sections) to strip out all unused code at link time. This decreases the size of a "hello world" executable for me from 716K to 482K with no measurable impact on link time. After this patch jemalloc is still the largest portion of our hello world executables, but this helps cut down on the size at least somewhat!
2014-12-24 22:20:01 -06:00
EXTRA_CFLAGS="-g1 -ffunction-sections -fdata-sections"
add back jemalloc to the tree This adds a `std::rt::heap` module with a nice allocator API. It's a step towards fixing #13094 and is a starting point for working on a generic allocator trait. The revision used for the jemalloc submodule is the stable 3.6.0 release. Closes #11807
2014-04-25 01:19:34 -05:00
$$(Q)$$(MAKE) -C "$$(JEMALLOC_BUILD_DIR_$(1))" build_lib_static
mk: Allow usage of a local jemalloc install This adds a new configure option, --jemalloc-root, which will specify a location at which libjemalloc_pic.a must live. This library is then used for the build triple as the jemalloc library to link.
2014-06-07 01:52:56 -05:00
ifeq ($(1),$$(CFG_BUILD))
ifneq ($$(CFG_JEMALLOC_ROOT),)
$$(JEMALLOC_LIB_$(1)): $$(CFG_JEMALLOC_ROOT)/libjemalloc_pic.a
@$$(call E, copy: jemalloc)
$$(Q)cp $$< $$@
else
mk: Allow using a locally compiled libuv.a Closes #5563
2014-06-10 12:01:21 -05:00
$$(JEMALLOC_LIB_$(1)): $$(JEMALLOC_LOCAL_$(1))
mk: Allow usage of a local jemalloc install This adds a new configure option, --jemalloc-root, which will specify a location at which libjemalloc_pic.a must live. This library is then used for the build triple as the jemalloc library to link.
2014-06-07 01:52:56 -05:00
$$(Q)cp $$< $$@
endif
else
mk: Allow using a locally compiled libuv.a Closes #5563
2014-06-10 12:01:21 -05:00
$$(JEMALLOC_LIB_$(1)): $$(JEMALLOC_LOCAL_$(1))
mk: Allow usage of a local jemalloc install This adds a new configure option, --jemalloc-root, which will specify a location at which libjemalloc_pic.a must live. This library is then used for the build triple as the jemalloc library to link.
2014-06-07 01:52:56 -05:00
$$(Q)cp $$< $$@
endif
add back jemalloc to the tree This adds a `std::rt::heap` module with a nice allocator API. It's a step towards fixing #13094 and is a starting point for working on a generic allocator trait. The revision used for the jemalloc submodule is the stable 3.6.0 release. Closes #11807
2014-04-25 01:19:34 -05:00
Build compiler-rt and link it to all crates, similarly to morestack.
2014-02-04 00:54:09 -06:00
################################################################################
# compiler-rt
################################################################################
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
# Everything below is a manual compilation of compiler-rt, disregarding its
# build system. See comments in `src/bootstrap/native.rs` for more information.
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
mk: Correct names of installed libs on windows Previously libmorestack.a and libcompiler-rt.a were installed, but link.exe looks for morestack.lib and compiler-rt.lib by default, so we need to install these with the correct name
2015-05-11 14:29:08 -05:00
COMPRT_NAME_$(1) := $$(call CFG_STATIC_LIB_NAME_$(1),compiler-rt)
Build compiler-rt and link it to all crates, similarly to morestack.
2014-02-04 00:54:09 -06:00
COMPRT_LIB_$(1) := $$(RT_OUTPUT_DIR_$(1))/$$(COMPRT_NAME_$(1))
COMPRT_BUILD_DIR_$(1) := $$(RT_OUTPUT_DIR_$(1))/compiler-rt
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
# GENERIC_SOURCES in CMakeLists.txt
COMPRT_OBJS_$(1) := \
absvdi2.o \
absvsi2.o \
adddf3.o \
addsf3.o \
addvdi3.o \
addvsi3.o \
apple_versioning.o \
ashldi3.o \
ashrdi3.o \
clear_cache.o \
clzdi2.o \
clzsi2.o \
cmpdi2.o \
comparedf2.o \
comparesf2.o \
ctzdi2.o \
ctzsi2.o \
divdc3.o \
divdf3.o \
divdi3.o \
divmoddi4.o \
divmodsi4.o \
divsc3.o \
divsf3.o \
divsi3.o \
divxc3.o \
extendsfdf2.o \
extendhfsf2.o \
ffsdi2.o \
fixdfdi.o \
fixdfsi.o \
fixsfdi.o \
fixsfsi.o \
fixunsdfdi.o \
fixunsdfsi.o \
fixunssfdi.o \
fixunssfsi.o \
fixunsxfdi.o \
fixunsxfsi.o \
fixxfdi.o \
floatdidf.o \
floatdisf.o \
floatdixf.o \
floatsidf.o \
floatsisf.o \
floatundidf.o \
floatundisf.o \
floatundixf.o \
floatunsidf.o \
floatunsisf.o \
int_util.o \
lshrdi3.o \
moddi3.o \
modsi3.o \
muldc3.o \
muldf3.o \
muldi3.o \
mulodi4.o \
mulosi4.o \
muloti4.o \
mulsc3.o \
mulsf3.o \
mulvdi3.o \
mulvsi3.o \
mulxc3.o \
negdf2.o \
negdi2.o \
negsf2.o \
negvdi2.o \
negvsi2.o \
paritydi2.o \
paritysi2.o \
popcountdi2.o \
popcountsi2.o \
powidf2.o \
powisf2.o \
powixf2.o \
subdf3.o \
subsf3.o \
subvdi3.o \
subvsi3.o \
truncdfhf2.o \
truncdfsf2.o \
truncsfhf2.o \
ucmpdi2.o \
udivdi3.o \
udivmoddi4.o \
udivmodsi4.o \
udivsi3.o \
umoddi3.o \
umodsi3.o
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
ifeq ($$(findstring ios,$(1)),)
COMPRT_OBJS_$(1) += \
absvti2.o \
addtf3.o \
addvti3.o \
ashlti3.o \
ashrti3.o \
clzti2.o \
cmpti2.o \
ctzti2.o \
divtf3.o \
divti3.o \
ffsti2.o \
fixdfti.o \
fixsfti.o \
fixunsdfti.o \
fixunssfti.o \
fixunsxfti.o \
fixxfti.o \
floattidf.o \
floattisf.o \
floattixf.o \
floatuntidf.o \
floatuntisf.o \
floatuntixf.o \
lshrti3.o \
modti3.o \
multf3.o \
multi3.o \
mulvti3.o \
negti2.o \
negvti2.o \
parityti2.o \
popcountti2.o \
powitf2.o \
subtf3.o \
subvti3.o \
trampoline_setup.o \
ucmpti2.o \
udivmodti4.o \
udivti3.o \
umodti3.o
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
endif
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
ifeq ($$(findstring apple,$(1)),apple)
COMPRT_OBJS_$(1) += \
atomic_flag_clear.o \
atomic_flag_clear_explicit.o \
atomic_flag_test_and_set.o \
atomic_flag_test_and_set_explicit.o \
atomic_signal_fence.o \
atomic_thread_fence.o
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
endif
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
ifeq ($$(findstring windows,$(1)),)
COMPRT_OBJS_$(1) += emutls.o
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
endif
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
ifeq ($$(findstring msvc,$(1)),)
COMPRT_OBJS_$(1) += gcc_personality_v0.o
COMPRT_OBJS_$(1) += emutls.o
ifeq ($$(findstring x86_64,$(1)),x86_64)
COMPRT_OBJS_$(1) += \
x86_64/chkstk.o \
x86_64/chkstk2.o \
x86_64/floatdidf.o \
x86_64/floatdisf.o \
x86_64/floatdixf.o \
x86_64/floatundidf.o \
x86_64/floatundisf.o \
x86_64/floatundixf.o
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
endif
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
ifeq ($$(findstring i686,$$(patsubts i%86,i686,$(1))),i686)
COMPRT_OBJS_$(1) += \
i386/ashldi3.o \
i386/ashrdi3.o \
i386/chkstk.o \
i386/chkstk2.o \
i386/divdi3.o \
i386/floatdidf.o \
i386/floatdisf.o \
i386/floatdixf.o \
i386/floatundidf.o \
i386/floatundisf.o \
i386/floatundixf.o \
i386/lshrdi3.o \
i386/moddi3.o \
i386/muldi3.o \
i386/udivdi3.o \
i386/umoddi3.o
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
endif
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
else
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
ifeq ($$(findstring x86_64,$(1)),x86_64)
COMPRT_OBJS_$(1) += \
x86_64/floatdidf.o \
x86_64/floatdisf.o \
x86_64/floatdixf.o
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
endif
endif
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
# Generic ARM sources, nothing compiles on iOS though
ifeq ($$(findstring arm,$(1)),arm)
ifeq ($$(findstring ios,$(1)),)
COMPRT_OBJS_$(1) += \
arm/aeabi_cdcmp.o \
arm/aeabi_cdcmpeq_check_nan.o \
arm/aeabi_cfcmp.o \
arm/aeabi_cfcmpeq_check_nan.o \
arm/aeabi_dcmp.o \
arm/aeabi_div0.o \
arm/aeabi_drsub.o \
arm/aeabi_fcmp.o \
arm/aeabi_frsub.o \
arm/aeabi_idivmod.o \
arm/aeabi_ldivmod.o \
arm/aeabi_memcmp.o \
arm/aeabi_memcpy.o \
arm/aeabi_memmove.o \
arm/aeabi_memset.o \
arm/aeabi_uidivmod.o \
arm/aeabi_uldivmod.o \
arm/bswapdi2.o \
arm/bswapsi2.o \
arm/clzdi2.o \
arm/clzsi2.o \
arm/comparesf2.o \
arm/divmodsi4.o \
arm/divsi3.o \
arm/modsi3.o \
arm/switch16.o \
arm/switch32.o \
arm/switch8.o \
arm/switchu8.o \
arm/sync_synchronize.o \
arm/udivmodsi4.o \
arm/udivsi3.o \
arm/umodsi3.o
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
endif
endif
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
# Thumb sources
ifeq ($$(findstring armv7,$(1)),armv7)
COMPRT_OBJS_$(1) += \
arm/sync_fetch_and_add_4.o \
arm/sync_fetch_and_add_8.o \
arm/sync_fetch_and_and_4.o \
arm/sync_fetch_and_and_8.o \
arm/sync_fetch_and_max_4.o \
arm/sync_fetch_and_max_8.o \
arm/sync_fetch_and_min_4.o \
arm/sync_fetch_and_min_8.o \
arm/sync_fetch_and_nand_4.o \
arm/sync_fetch_and_nand_8.o \
arm/sync_fetch_and_or_4.o \
arm/sync_fetch_and_or_8.o \
arm/sync_fetch_and_sub_4.o \
arm/sync_fetch_and_sub_8.o \
arm/sync_fetch_and_umax_4.o \
arm/sync_fetch_and_umax_8.o \
arm/sync_fetch_and_umin_4.o \
arm/sync_fetch_and_umin_8.o \
arm/sync_fetch_and_xor_4.o \
arm/sync_fetch_and_xor_8.o
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
endif
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
# VFP sources
ifeq ($$(findstring eabihf,$(1)),eabihf)
COMPRT_OBJS_$(1) += \
arm/adddf3vfp.o \
arm/addsf3vfp.o \
arm/divdf3vfp.o \
arm/divsf3vfp.o \
arm/eqdf2vfp.o \
arm/eqsf2vfp.o \
arm/extendsfdf2vfp.o \
arm/fixdfsivfp.o \
arm/fixsfsivfp.o \
arm/fixunsdfsivfp.o \
arm/fixunssfsivfp.o \
arm/floatsidfvfp.o \
arm/floatsisfvfp.o \
arm/floatunssidfvfp.o \
arm/floatunssisfvfp.o \
arm/gedf2vfp.o \
arm/gesf2vfp.o \
arm/gtdf2vfp.o \
arm/gtsf2vfp.o \
arm/ledf2vfp.o \
arm/lesf2vfp.o \
arm/ltdf2vfp.o \
arm/ltsf2vfp.o \
arm/muldf3vfp.o \
arm/mulsf3vfp.o \
arm/negdf2vfp.o \
arm/negsf2vfp.o \
arm/nedf2vfp.o \
arm/nesf2vfp.o \
arm/restore_vfp_d8_d15_regs.o \
arm/save_vfp_d8_d15_regs.o \
arm/subdf3vfp.o \
arm/subsf3vfp.o \
arm/truncdfsf2vfp.o \
arm/unorddf2vfp.o \
arm/unordsf2vfp.o
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
endif
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
ifeq ($$(findstring aarch64,$(1)),aarch64)
COMPRT_OBJS_$(1) += \
comparetf2.o \
extenddftf2.o \
extendsftf2.o \
fixtfdi.o \
fixtfsi.o \
fixtfti.o \
fixunstfdi.o \
fixunstfsi.o \
fixunstfti.o \
floatditf.o \
floatsitf.o \
floatunditf.o \
floatunsitf.o \
multc3.o \
trunctfdf2.o \
trunctfsf2.o
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
endif
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
ifeq ($$(findstring msvc,$(1)),msvc)
$$(COMPRT_BUILD_DIR_$(1))/%.o: CFLAGS += -Zl -D__func__=__FUNCTION__
mk: Add support for i686-pc-windows-msvc This commit modifies the configure script and our makefiles to support building 32-bit MSVC targets. The MSVC toolchain is now parameterized over whether it can produce a 32-bit or 64-bit binary. The configure script was updated to export more variables at configure time, and the makefiles were rejiggered to selectively reexport the relevant environment variables for the applicable targets they're going to run for.
2015-06-25 17:30:00 -05:00
else
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
$$(COMPRT_BUILD_DIR_$(1))/%.o: CFLAGS += -fno-builtin -fvisibility=hidden \
-fomit-frame-pointer -ffreestanding
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
endif
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
COMPRT_OBJS_$(1) := $$(COMPRT_OBJS_$(1):%=$$(COMPRT_BUILD_DIR_$(1))/%)
$$(COMPRT_BUILD_DIR_$(1))/%.o: $(S)src/compiler-rt/lib/builtins/%.c
@mkdir -p $$(@D)
@$$(call E, compile: $$@)
$$(Q)$$(call CFG_COMPILE_C_$(1),$$@,$$<)
$$(COMPRT_BUILD_DIR_$(1))/%.o: $(S)src/compiler-rt/lib/builtins/%.S \
$$(LLVM_CONFIG_$$(CFG_BUILD))
@mkdir -p $$(@D)
@$$(call E, compile: $$@)
$$(Q)$$(call CFG_ASSEMBLE_$(1),$$@,$$<)
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
ifeq ($$(findstring msvc,$(1)),msvc)
$$(COMPRT_BUILD_DIR_$(1))/%.o: \
export INCLUDE := $$(CFG_MSVC_INCLUDE_PATH_$$(HOST_$(1)))
mk: Add support for i686-pc-windows-msvc This commit modifies the configure script and our makefiles to support building 32-bit MSVC targets. The MSVC toolchain is now parameterized over whether it can produce a 32-bit or 64-bit binary. The configure script was updated to export more variables at configure time, and the makefiles were rejiggered to selectively reexport the relevant environment variables for the applicable targets they're going to run for.
2015-06-25 17:30:00 -05:00
endif
mk: Fix building compiler-rt on MSVC It looks like compiler-rt has a cmake build sytem inside its source, but I have been unable to figure out how to use it and actually build the right library. For now this commit hard-wires MSVC-targeting builds of libcompiler-rt to continue using `make` as the primary bulid system, but some frobbing of the flags are necessary to ensure that the right compiler is used.
2015-05-11 16:09:25 -05:00
Add the asmjs-unknown-emscripten triple. Add cfgs to libs. Backtraces, and the compilation of libbacktrace for asmjs, are disabled. This port doesn't use jemalloc so, like pnacl, it disables jemalloc *for all targets* in the configure file. It disables stack protection.
2015-11-26 13:05:10 -06:00
ifeq ($$(findstring emscripten,$(1)),emscripten)
# FIXME: emscripten doesn't use compiler-rt and can't build it without
# further hacks
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
COMPRT_OBJS_$(1) :=
llvm: allow cleaning LLVM's Visual Studio builds The Visual Studio generators create a `clean` target that we can use.
2016-07-01 19:19:23 -05:00
endif
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt, especially across platforms. * The standard build system doesn't actually do what we want, not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled, which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions), and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code, the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt, but that seems like a much less significant cost to pay than what we're currently paying. cc #34400, first steps towards that
2016-07-16 17:08:25 -05:00
$$(COMPRT_LIB_$(1)): $$(COMPRT_OBJS_$(1))
@$$(call E, link: $$@)
$$(Q)$$(call CFG_CREATE_ARCHIVE_$(1),$$@) $$^
Add the asmjs-unknown-emscripten triple. Add cfgs to libs. Backtraces, and the compilation of libbacktrace for asmjs, are disabled. This port doesn't use jemalloc so, like pnacl, it disables jemalloc *for all targets* in the configure file. It disables stack protection.
2015-11-26 13:05:10 -06:00
Add basic backtrace functionality Whenever a failure happens, if a program is run with `RUST_LOG=std::rt::backtrace` a backtrace will be printed to the task's stderr handle. Stack traces are uncondtionally printed on double-failure and rtabort!(). This ended up having a nontrivial implementation, and here's some highlights of it: * We're bundling libbacktrace for everything but OSX and Windows * We use libgcc_s and its libunwind apis to get a backtrace of instruction pointers * On OSX we use dladdr() to go from an instruction pointer to a symbol * On unix that isn't OSX, we use libbacktrace to get symbols * Windows, as usual, has an entirely separate implementation Lots more fun details and comments can be found in the source itself. Closes #10128
2014-02-05 17:19:40 -06:00
################################################################################
# libbacktrace
#
# We use libbacktrace on linux to get symbols in backtraces, but only on linux.
# Elsewhere we use other system utilities, so this library is only built on
# linux.
################################################################################
BACKTRACE_NAME_$(1) := $$(call CFG_STATIC_LIB_NAME_$(1),backtrace)
BACKTRACE_LIB_$(1) := $$(RT_OUTPUT_DIR_$(1))/$$(BACKTRACE_NAME_$(1))
BACKTRACE_BUILD_DIR_$(1) := $$(RT_OUTPUT_DIR_$(1))/libbacktrace
Add line numbers to windows-gnu backtraces Fix formatting Remove unused imports Refactor Fix msvc build Fix line lengths Formatting Enable backtrace tests Fix using directive on mac pwd info Work-around buildbot PWD bug, and fix libbacktrace configuration Use alternative to `env -u` which is not supported on bitrig Disable tests on 32-bit windows gnu
2015-08-25 19:44:55 -05:00
# We don't use this on platforms that aren't linux-based (with the exception of
# msys2/mingw builds on windows, which use it to read the dwarf debug
# information) so just make the file available, the compilation of libstd won't
# actually build it.
Platform configuration FIXME: avoid using Xcode build and switch to a patched libuv
2014-05-05 02:05:11 -05:00
ifeq ($$(findstring darwin,$$(OSTYPE_$(1))),darwin)
# See comment above
Add basic backtrace functionality Whenever a failure happens, if a program is run with `RUST_LOG=std::rt::backtrace` a backtrace will be printed to the task's stderr handle. Stack traces are uncondtionally printed on double-failure and rtabort!(). This ended up having a nontrivial implementation, and here's some highlights of it: * We're bundling libbacktrace for everything but OSX and Windows * We use libgcc_s and its libunwind apis to get a backtrace of instruction pointers * On OSX we use dladdr() to go from an instruction pointer to a symbol * On unix that isn't OSX, we use libbacktrace to get symbols * Windows, as usual, has an entirely separate implementation Lots more fun details and comments can be found in the source itself. Closes #10128
2014-02-05 17:19:40 -06:00
$$(BACKTRACE_LIB_$(1)):
touch $$@
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
else ifeq ($$(findstring ios,$$(OSTYPE_$(1))),ios)
Platform configuration FIXME: avoid using Xcode build and switch to a patched libuv
2014-05-05 02:05:11 -05:00
# See comment above
$$(BACKTRACE_LIB_$(1)):
touch $$@
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
else ifeq ($$(findstring msvc,$(1)),msvc)
Platform configuration FIXME: avoid using Xcode build and switch to a patched libuv
2014-05-05 02:05:11 -05:00
# See comment above
Add basic backtrace functionality Whenever a failure happens, if a program is run with `RUST_LOG=std::rt::backtrace` a backtrace will be printed to the task's stderr handle. Stack traces are uncondtionally printed on double-failure and rtabort!(). This ended up having a nontrivial implementation, and here's some highlights of it: * We're bundling libbacktrace for everything but OSX and Windows * We use libgcc_s and its libunwind apis to get a backtrace of instruction pointers * On OSX we use dladdr() to go from an instruction pointer to a symbol * On unix that isn't OSX, we use libbacktrace to get symbols * Windows, as usual, has an entirely separate implementation Lots more fun details and comments can be found in the source itself. Closes #10128
2014-02-05 17:19:40 -06:00
$$(BACKTRACE_LIB_$(1)):
touch $$@
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
else ifeq ($$(findstring emscripten,$(1)),emscripten)
Add the asmjs-unknown-emscripten triple. Add cfgs to libs. Backtraces, and the compilation of libbacktrace for asmjs, are disabled. This port doesn't use jemalloc so, like pnacl, it disables jemalloc *for all targets* in the configure file. It disables stack protection.
2015-11-26 13:05:10 -06:00
# FIXME: libbacktrace doesn't understand the emscripten triple
$$(BACKTRACE_LIB_$(1)):
touch $$@
else
Add basic backtrace functionality Whenever a failure happens, if a program is run with `RUST_LOG=std::rt::backtrace` a backtrace will be printed to the task's stderr handle. Stack traces are uncondtionally printed on double-failure and rtabort!(). This ended up having a nontrivial implementation, and here's some highlights of it: * We're bundling libbacktrace for everything but OSX and Windows * We use libgcc_s and its libunwind apis to get a backtrace of instruction pointers * On OSX we use dladdr() to go from an instruction pointer to a symbol * On unix that isn't OSX, we use libbacktrace to get symbols * Windows, as usual, has an entirely separate implementation Lots more fun details and comments can be found in the source itself. Closes #10128
2014-02-05 17:19:40 -06:00
ifdef CFG_ENABLE_FAST_MAKE
BACKTRACE_DEPS := $(S)/.gitmodules
else
BACKTRACE_DEPS := $(wildcard $(S)src/libbacktrace/*)
endif
# We need to export CFLAGS because otherwise it doesn't pick up cross compile
# builds. If libbacktrace doesn't realize this, it will attempt to read 64-bit
# elf headers when compiled for a 32-bit system, yielding blank backtraces.
#
# This also removes the -Werror flag specifically to prevent errors during
# configuration.
#
# Down below you'll also see echos into the config.h generated by the
# ./configure script. This is done to force libbacktrace to *not* use the
# atomic/sync functionality because it pulls in unnecessary dependencies and we
# never use it anyway.
Add line numbers to windows-gnu backtraces Fix formatting Remove unused imports Refactor Fix msvc build Fix line lengths Formatting Enable backtrace tests Fix using directive on mac pwd info Work-around buildbot PWD bug, and fix libbacktrace configuration Use alternative to `env -u` which is not supported on bitrig Disable tests on 32-bit windows gnu
2015-08-25 19:44:55 -05:00
#
# We also use `env PWD=` to clear the PWD environment variable, and then
# execute the command in a new shell. This is necessary to workaround a
# buildbot/msys2 bug: the shell is launched with PWD set to a windows-style path,
# which results in all further uses of `pwd` also printing a windows-style path,
# which breaks libbacktrace's configure script. Clearing PWD within the same
# shell is not sufficient.
Add basic backtrace functionality Whenever a failure happens, if a program is run with `RUST_LOG=std::rt::backtrace` a backtrace will be printed to the task's stderr handle. Stack traces are uncondtionally printed on double-failure and rtabort!(). This ended up having a nontrivial implementation, and here's some highlights of it: * We're bundling libbacktrace for everything but OSX and Windows * We use libgcc_s and its libunwind apis to get a backtrace of instruction pointers * On OSX we use dladdr() to go from an instruction pointer to a symbol * On unix that isn't OSX, we use libbacktrace to get symbols * Windows, as usual, has an entirely separate implementation Lots more fun details and comments can be found in the source itself. Closes #10128
2014-02-05 17:19:40 -06:00
$$(BACKTRACE_BUILD_DIR_$(1))/Makefile: $$(BACKTRACE_DEPS) $$(MKFILE_DEPS)
mk/rt: "export CC" does not seem to work (gcc observed), use explicit shell variables instead
2014-10-20 13:04:45 -05:00
@$$(call E, configure: libbacktrace for $(1))
Add basic backtrace functionality Whenever a failure happens, if a program is run with `RUST_LOG=std::rt::backtrace` a backtrace will be printed to the task's stderr handle. Stack traces are uncondtionally printed on double-failure and rtabort!(). This ended up having a nontrivial implementation, and here's some highlights of it: * We're bundling libbacktrace for everything but OSX and Windows * We use libgcc_s and its libunwind apis to get a backtrace of instruction pointers * On OSX we use dladdr() to go from an instruction pointer to a symbol * On unix that isn't OSX, we use libbacktrace to get symbols * Windows, as usual, has an entirely separate implementation Lots more fun details and comments can be found in the source itself. Closes #10128
2014-02-05 17:19:40 -06:00
$$(Q)rm -rf $$(BACKTRACE_BUILD_DIR_$(1))
$$(Q)mkdir -p $$(BACKTRACE_BUILD_DIR_$(1))
Add line numbers to windows-gnu backtraces Fix formatting Remove unused imports Refactor Fix msvc build Fix line lengths Formatting Enable backtrace tests Fix using directive on mac pwd info Work-around buildbot PWD bug, and fix libbacktrace configuration Use alternative to `env -u` which is not supported on bitrig Disable tests on 32-bit windows gnu
2015-08-25 19:44:55 -05:00
$$(Q)(cd $$(BACKTRACE_BUILD_DIR_$(1)) && env \
PWD= \
mk/rt: "export CC" does not seem to work (gcc observed), use explicit shell variables instead
2014-10-20 13:04:45 -05:00
CC="$$(CC_$(1))" \
AR="$$(AR_$(1))" \
RANLIB="$$(AR_$(1)) s" \
More reliable and consistent method of cancelling -Werror* Adding -Wno-error is more reliable and simple than trying to modify existing flags. We've been using this in Debian already for the past few releases. Making this change also encourages future maintainers towards "best practises". Also take the opportunity to use the same method at all places in the file.
2016-01-24 04:07:47 -06:00
CFLAGS="$$(CFG_GCCISH_CFLAGS_$(1)) -Wno-error -fno-stack-protector" \
Add line numbers to windows-gnu backtraces Fix formatting Remove unused imports Refactor Fix msvc build Fix line lengths Formatting Enable backtrace tests Fix using directive on mac pwd info Work-around buildbot PWD bug, and fix libbacktrace configuration Use alternative to `env -u` which is not supported on bitrig Disable tests on 32-bit windows gnu
2015-08-25 19:44:55 -05:00
$(S)src/libbacktrace/configure --build=$(CFG_GNU_TRIPLE_$(CFG_BUILD)) --host=$(CFG_GNU_TRIPLE_$(1)))
Add basic backtrace functionality Whenever a failure happens, if a program is run with `RUST_LOG=std::rt::backtrace` a backtrace will be printed to the task's stderr handle. Stack traces are uncondtionally printed on double-failure and rtabort!(). This ended up having a nontrivial implementation, and here's some highlights of it: * We're bundling libbacktrace for everything but OSX and Windows * We use libgcc_s and its libunwind apis to get a backtrace of instruction pointers * On OSX we use dladdr() to go from an instruction pointer to a symbol * On unix that isn't OSX, we use libbacktrace to get symbols * Windows, as usual, has an entirely separate implementation Lots more fun details and comments can be found in the source itself. Closes #10128
2014-02-05 17:19:40 -06:00
$$(Q)echo '#undef HAVE_ATOMIC_FUNCTIONS' >> \
$$(BACKTRACE_BUILD_DIR_$(1))/config.h
$$(Q)echo '#undef HAVE_SYNC_FUNCTIONS' >> \
$$(BACKTRACE_BUILD_DIR_$(1))/config.h
$$(BACKTRACE_LIB_$(1)): $$(BACKTRACE_BUILD_DIR_$(1))/Makefile $$(MKFILE_DEPS)
@$$(call E, make: libbacktrace)
$$(Q)$$(MAKE) -C $$(BACKTRACE_BUILD_DIR_$(1)) \
INCDIR=$(S)src/libbacktrace
$$(Q)cp $$(BACKTRACE_BUILD_DIR_$(1))/.libs/libbacktrace.a $$@
Convert makefiles to build LLVM/compiler-rt with CMake
2016-06-01 19:41:27 -05:00
endif
Add basic backtrace functionality Whenever a failure happens, if a program is run with `RUST_LOG=std::rt::backtrace` a backtrace will be printed to the task's stderr handle. Stack traces are uncondtionally printed on double-failure and rtabort!(). This ended up having a nontrivial implementation, and here's some highlights of it: * We're bundling libbacktrace for everything but OSX and Windows * We use libgcc_s and its libunwind apis to get a backtrace of instruction pointers * On OSX we use dladdr() to go from an instruction pointer to a symbol * On unix that isn't OSX, we use libbacktrace to get symbols * Windows, as usual, has an entirely separate implementation Lots more fun details and comments can be found in the source itself. Closes #10128
2014-02-05 17:19:40 -06:00
mk: Add support for musl-based builds This commit adds support to the makefiles, configuration script, and build system to understand MUSL. This is broken up into a few parts: * Any target of the form `*-musl` requires the `--musl-root` option to `./configure` which will indicate the root of the MUSL installation. It is also expected that there is a libunwind build inside of that installation built against that MUSL. * Objects from MUSL are copied into the build tree for Rust to be statically linked into the appropriate Rust library. * Objects for binary startup and shutdown are included in each Rust installation by default for MUSL. This requires MUSL to only be installed on the machine compiling rust. Only a linker will be necessary for compiling against MUSL on a target machine. Eventually a MUSL and/or libunwind build may be integrated by default into the build but for now they are just always assumed to exist externally.
2015-04-21 17:42:05 -05:00
################################################################################
# libc/libunwind for musl
#
# When we're building a musl-like target we're going to link libc/libunwind
# statically into the standard library and liblibc, so we need to make sure
# they're in a location that we can find
################################################################################
ifeq ($$(findstring musl,$(1)),musl)
$$(RT_OUTPUT_DIR_$(1))/%: $$(CFG_MUSL_ROOT)/lib/%
cp $$^ $$@
Make sure rsbegin.o and rsend.o get packaged with target lib artifacts. Also, unified libc startup objects finding logic with that of the `-musl` target, since conceptually they were doing the same thing.
2015-11-07 19:44:44 -06:00
else
# Ask gcc where it is
$$(RT_OUTPUT_DIR_$(1))/%:
cp $$(shell $$(CC_$(1)) -print-file-name=$$(@F)) $$@
mk: Add support for musl-based builds This commit adds support to the makefiles, configuration script, and build system to understand MUSL. This is broken up into a few parts: * Any target of the form `*-musl` requires the `--musl-root` option to `./configure` which will indicate the root of the MUSL installation. It is also expected that there is a libunwind build inside of that installation built against that MUSL. * Objects from MUSL are copied into the build tree for Rust to be statically linked into the appropriate Rust library. * Objects for binary startup and shutdown are included in each Rust installation by default for MUSL. This requires MUSL to only be installed on the machine compiling rust. Only a linker will be necessary for compiling against MUSL on a target machine. Eventually a MUSL and/or libunwind build may be integrated by default into the build but for now they are just always assumed to exist externally.
2015-04-21 17:42:05 -05:00
endif
virtualize the runtime per target triple.
2011-11-01 18:50:47 -05:00
endef
Build libuv/jemalloc only once (not per stage) Reorganize the makefiles to stop building these once per stage because there's no need to do this at all. Closes #7002
2013-10-08 11:20:17 -05:00
# Instantiate template for all stages/targets
support for GNU configure syntax
2013-10-21 04:18:21 -05:00
$(foreach target,$(CFG_TARGET), \
Build libuv/jemalloc only once (not per stage) Reorganize the makefiles to stop building these once per stage because there's no need to do this at all. Closes #7002
2013-10-08 11:20:17 -05:00
$(eval $(call DEF_THIRD_PARTY_TARGETS,$(target))))
Reference in New Issue Copy Permalink