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

353 lines
13 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.
################################################################################
Register new snapshots * Lots of core prelude imports removed * Makefile support for MSVC env vars and Rust crates removed * Makefile support for morestack removed
2015-08-11 16:31:23 -05:00
NATIVE_LIBS := rust_builtin 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
std: Extract librustrt out of libstd As part of the libstd facade efforts, this commit extracts the runtime interface out of the standard library into a standalone crate, librustrt. This crate will provide the following services: * Definition of the rtio interface * Definition of the Runtime interface * Implementation of the Task structure * Implementation of task-local-data * Implementation of task failure via unwinding via libunwind * Implementation of runtime initialization and shutdown * Implementation of thread-local-storage for the local rust Task Notably, this crate avoids the following services: * Thread creation and destruction. The crate does not require the knowledge of an OS threading system, and as a result it seemed best to leave out the `rt::thread` module from librustrt. The librustrt module does depend on mutexes, however. * Implementation of backtraces. There is no inherent requirement for the runtime to be able to generate backtraces. As will be discussed later, this functionality continues to live in libstd rather than librustrt. As usual, a number of architectural changes were required to make this crate possible. Users of "stable" functionality will not be impacted by this change, but users of the `std::rt` module will likely note the changes. A list of architectural changes made is: * The stdout/stderr handles no longer live directly inside of the `Task` structure. This is a consequence of librustrt not knowing about `std::io`. These two handles are now stored inside of task-local-data. The handles were originally stored inside of the `Task` for perf reasons, and TLD is not currently as fast as it could be. For comparison, 100k prints goes from 59ms to 68ms (a 15% slowdown). This appeared to me to be an acceptable perf loss for the successful extraction of a librustrt crate. * The `rtio` module was forced to duplicate more functionality of `std::io`. As the module no longer depends on `std::io`, `rtio` now defines structures such as socket addresses, addrinfo fiddly bits, etc. The primary change made was that `rtio` now defines its own `IoError` type. This type is distinct from `std::io::IoError` in that it does not have an enum for what error occurred, but rather a platform-specific error code. The native and green libraries will be updated in later commits for this change, and the bulk of this effort was put behind updating the two libraries for this change (with `rtio`). * Printing a message on task failure (along with the backtrace) continues to live in libstd, not in librustrt. This is a consequence of the above decision to move the stdout/stderr handles to TLD rather than inside the `Task` itself. The unwinding API now supports registration of global callback functions which will be invoked when a task fails, allowing for libstd to register a function to print a message and a backtrace. The API for registering a callback is experimental and unsafe, as the ramifications of running code on unwinding is pretty hairy. * The `std::unstable::mutex` module has moved to `std::rt::mutex`. * The `std::unstable::sync` module has been moved to `std::rt::exclusive` and the type has been rewritten to not internally have an Arc and to have an RAII guard structure when locking. Old code should stop using `Exclusive` in favor of the primitives in `libsync`, but if necessary, old code should port to `Arc<Exclusive<T>>`. * The local heap has been stripped down to have fewer debugging options. None of these were tested, and none of these have been used in a very long time. [breaking-change]
2014-06-03 21:11:49 -05:00
NATIVE_DEPS_rust_builtin_$(1) := rust_builtin.c \
rust_android_dummy.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
mk: Remove extra whitespace before line continuation backslashes
2014-07-22 23:37:05 -05:00
$(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 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
ifeq ($$(CFG_WINDOWSY_$(1)), 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
# This isn't necessarily a desired option, but it's harmless and works around
# what appears to be a mingw-w64 bug.
#
# https://sourceforge.net/p/mingw-w64/bugs/395/
JEMALLOC_ARGS_$(1) := --enable-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)
Initial support for aarch64-linux-android
2015-01-20 00:03:44 -06:00
JEMALLOC_ARGS_$(1) := --disable-tls
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.
JEMALLOC_DEPS := $(filter-out $(S)src/jemalloc/VERSION,$(JEMALLOC_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
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" \
enable jemalloc debugging in unoptimized builds The performance hit from these checks is significant, but unoptimized builds are already incredibly slow. Enabling these checks results in better test coverage since there are bots doing unoptimized builds, and the cost is relatively small in the context of an unoptimized build. This also allows using `JEMALLOC_FLAGS` to override the default configure flags.
2014-09-07 13:05:32 -05:00
$$(JEMALLOC_ARGS_$(1)) --with-jemalloc-prefix=je_ $(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
################################################################################
ifdef CFG_ENABLE_FAST_MAKE
COMPRT_DEPS := $(S)/.gitmodules
else
COMPRT_DEPS := $(wildcard \
$(S)src/compiler-rt/* \
$(S)src/compiler-rt/*/* \
$(S)src/compiler-rt/*/*/* \
$(S)src/compiler-rt/*/*/*/*)
endif
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: 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
# Note that on MSVC-targeting builds we hardwire CC/AR to gcc/ar even though
# we're targeting MSVC. This is because although compiler-rt has a CMake build
# config I can't actually figure out how to use it, so I'm not sure how to use
# cl.exe to build the objects. Additionally, the compiler-rt library when built
# with gcc has the same ABI as cl.exe, so they're largely compatible
COMPRT_CC_$(1) := $$(CC_$(1))
COMPRT_AR_$(1) := $$(AR_$(1))
COMPRT_CFLAGS_$(1) := $$(CFG_GCCISH_CFLAGS_$(1))
ifeq ($$(findstring msvc,$(1)),msvc)
COMPRT_CC_$(1) := gcc
COMPRT_AR_$(1) := ar
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
ifeq ($$(findstring i686,$(1)),i686)
COMPRT_CFLAGS_$(1) := $$(CFG_GCCISH_CFLAGS_$(1)) -m32
else
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
COMPRT_CFLAGS_$(1) := $$(CFG_GCCISH_CFLAGS_$(1)) -m64
endif
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 MKFILE_DEPS to compiler-rt target Currently when you run `make -jN` it's likely that you'll remove compiler-rt and then it won't get cp'd back into the right place. I believe the reason for this is that the compiler-rt library target never got updated so make decided it never needed to copy the files back into place. The files were all there at the beginning of `make`, but then we may clean out the stage0 versions if we unzip the snapshot again.
2014-02-14 10:13:19 -06:00
$$(COMPRT_LIB_$(1)): $$(COMPRT_DEPS) $$(MKFILE_DEPS)
Build compiler-rt and link it to all crates, similarly to morestack.
2014-02-04 00:54:09 -06:00
@$$(call E, make: compiler-rt)
$$(Q)$$(MAKE) -C "$(S)src/compiler-rt" \
ProjSrcRoot="$(S)src/compiler-rt" \
ProjObjRoot="$$(abspath $$(COMPRT_BUILD_DIR_$(1)))" \
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
CC='$$(COMPRT_CC_$(1))' \
AR='$$(COMPRT_AR_$(1))' \
RANLIB='$$(COMPRT_AR_$(1)) s' \
CFLAGS="$$(COMPRT_CFLAGS_$(1))" \
Build compiler-rt and link it to all crates, similarly to morestack.
2014-02-04 00:54:09 -06:00
TargetTriple=$(1) \
Upgrade compiler-rt
2014-04-21 20:43:19 -05:00
triple-builtins
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
$$(Q)cp $$(COMPRT_BUILD_DIR_$(1))/triple/builtins/libcompiler_rt.a $$@
Build compiler-rt and link it to all crates, similarly to morestack.
2014-02-04 00:54:09 -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 $$@
else
Platform configuration FIXME: avoid using Xcode build and switch to a patched libuv
2014-05-05 02:05:11 -05:00
ifeq ($$(findstring ios,$$(OSTYPE_$(1))),ios)
# See comment above
$$(BACKTRACE_LIB_$(1)):
touch $$@
else
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
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 $$@
else
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" \
CFLAGS="$$(CFG_GCCISH_CFLAGS_$(1):-Werror=) -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 $$@
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
endif # endif for msvc
Platform configuration FIXME: avoid using Xcode build and switch to a patched libuv
2014-05-05 02:05:11 -05:00
endif # endif for ios
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
endif # endif for darwin
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 $$^ $$@
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