ccache is a build tool that can help speed up redundant compilations. It's not strictly necessary; you can disable it by adding `ENABLE_CCACHE := 0` to your Makefile.local. It's enabled by default, so to use it you can run
ccache is a build tool that can help speed up redundant compilations. It's not strictly necessary; you can disable it by adding `USE_CCACHE := 0` to your Makefile.local. It's enabled by default, so to use it you can run
LLVM and clang depend on a pretty modern compiler; the steps below assume yo uinstalled GCC 4.8.2 as described above. It should be possible to build using clang >= 3.1, such as what you might find on a Mac, but that will require changes to the following setup that I haven't tested.
LLVM and clang depend on a pretty modern compiler; the steps below assume you uinstalled GCC 4.8.2 as described above. It should be possible to build using clang >= 3.1, such as what you might find on a Mac, but that will require changes to the way LLVM is configured (specified in src/Makefile) that I haven't tested.
```
cd ~/pyston_deps
...
...
@@ -51,7 +51,7 @@ make llvm_configure
make llvm -j4
```
There seem to be some lingering build issues with LLVM that I haven't identified; if the last step fails with errors along the lines of "rm: could not find file foo.tmp", it is quite likely that simply running it again will have it continue successfully. You may have to do this multiple times, unfortunately.
There seem to be some lingering issues with the LLVM build that haven't been identified yet; if the last step fails with errors along the lines of "rm: could not find file foo.tmp", it is quite likely that simply running it again will cause it to continue successfully. You may have to do this multiple times, unfortunately.
### libunwind
...
...
@@ -69,7 +69,7 @@ TODO would be nice to install this locally like the rest of the dependencies
### valgrind
valgrind is close to being an optional dependency, but since Pyston contains a custom memory allocator, it has some basic (and mostly-broken) valgrind hooks to let it know what memory is safe to access or not. TODO it'd be nice to be able to turn that off by default.
valgrind is close to being an optional dependency, but since Pyston contains a custom memory allocator, it has some basic (and mostly-broken) valgrind hooks to let it know what memory is safe to access or not. TODO it'd be nice to be able to turn that off with a Makefile flag since it's not useful for most people.
You may be able to install valgrind from your system package manager (`apt-get install valgrind`), but it is likely to be an old enough version that it doesn't support some newer instructions and may crash when running. The safest thing to do is to do a full installation from source:
A new version of gdb can be highly useful since debugging a JIT tends to stress GDB:
A new version of gdb is highly recommended since debugging a JIT tends to stress GDB:
```
cd ~/pyston_deps
...
...
@@ -132,7 +137,7 @@ standard ./configure, make, make install
### gold
gold is highly recommended as a faster linker. Pyston contains build-system support for automatically using gold if available. gold may already be installed on your system; you can check by typing `which gold`.
gold is highly recommended as a faster linker. Pyston contains build-system support for automatically using gold if available. gold may already be installed on your system; you can check by typing `which gold`. If it's not installed already:
# Make sure that we put all symbols in the dynamic symbol table so that MCJIT can load them;
# TODO should probably do the linking before MCJIT
COMMON_LDFLAGS+=-Wl,-E
# For now, link in libstdc++ statically, since the system libstdc++ is likely to be too old:
# The system libstdc++ will likely be too old for Pyston, but we made a brand new one
# as part of our GCC installation. There are a couple ways to use that one instead:
# 1) Install the built libstdc++ (~/pyston_deps/gcc-4.8.2-install/lib64/libstdc++.so.6.0.18) and update the global shared library (/usr/local/x86_64-linux-gnu/libstdc++.so.6) to point to it
# 2) Set LD_LIBRARY_PATH=~/pyston_deps/gcc-4.8.2-install/lib64
# 3) Link it in statically.
#
# For now, go with option #3 since it is the only one that requires no extra work for people who want to run Pyston.
#
# (I was surprised by this issue: the linker sees the shared library that we built
# as part of GCC and decides to dynamically link to that, even though at load time we'll
# end up linking to the system libstdc++ instead.)
