# This uses 3 build processes, you need 2GB of RAM for each.
./build.sh -j3
```
### Building On Ubuntu 16.04 and older systems
Some older compilers may not be able to compile modern code, such as gcc 5.4 which comes with Ubuntu 16.04 by default. Here is how to install gcc 7 on Ubuntu 16.04. Run these commands as root:
Finally to compile the software you use `./build.sh` . It is quite slow
to only use a single thread, so you can use multiple threads, for example 4,
like this:
```
./build.sh -j4
```
Each `build.sh` thread will take ~2GB of RAM so beware of that. If you have
compiled before and just made a change to C++ code, you can probably use
`make` instead and use a high number of threads. For example, if your CPU
has 8 physical cores and 16 "virtual cores" then you can use `make -j16` and
things will compile much faster. Each `make` threads takes only about 200MB of RAM.
If `make` fails in a weird way complaining about Makefiles, you probably need to
run `build.sh`, which takes care of regenerating Makefiles and installing some
additional dependencies.
Sometimes using multiple threads the build can fail, so if it does, try again
with a different number of threads or just one thread before reporting an issue.
# Fresh sync
Many times, you will want to do a "fresh sync" test, to verify code works when syncing from the genesis block, which is a different code path than a "partial sync" which means you already have part of blockchain history and are "catching up" to get in sync.
It's possible to confused hush if you ran old code, stop, restart, and then write out zindex.dat that is incorrect, which later hushds will load from disk and believe.
# Generating a backtrace from a coredump
Sometimes the code coredumps, what are ya gonna do? Generate a backtrace, of course.
Run `ulimit -c unlimited` to make sure your shell will generate coredumps and
then run the application which coredumps. In the Olden Times Linux would always
make the "core" file in the same dir as the binary that was run which created
it. But I have now seen that some new Linux distributions put them in weird
places, for instance Arch puts them in /var/lib/systemd/coredump . If there are
lots of coredumps and you don't know which one is the latest, sort them by
modification time `ls -lart` or just delete them all and run the code which
generates the core dump. Old coredumps are not very useful and take up lots of space.
Once you have a coredump file (which is usually called "core" or "core.XYZ"
where XYZ is the PID that generated it) you can then type `gdb binary_name
core_filename` and then type bt to generate the backtrace.
For this repo, it's likely this is the command you need:
```
gdb src/hushd core
```
NOTE: Even if you are debugging a coredump on a HAC, such as DragonX, the file `src/dragonxd`
is just a shell script that calls `src/hushd` and you always want to give an actual executable
file as the first argument to `gdb`, not a bash script.
This link about Advanced GDB is very useful: https://interrupt.memfault.com/blog/advanced-gdb
# Parsing RPC output with jq
jq is a very useful tool to parse JSON output, install it with:
@ -182,15 +260,14 @@ error and debugging messages are written there.
The -debug=... command-line option controls debugging; running with just -debug or -debug=1 will turn
on all categories (and give you a very large debug.log file).
**testnet and regtest modes**
**test coins**
Run with the -testnet option to run with "play HUSH" on the test network, if you
are testing multi-machine code that needs to operate across the internet. You can
also make a Hush Smart Chain "testcoin" with a single command: `hushd -ac_name=COIN ...`
The main way to test new things is directly on mainnet or you can also make a
Hush Arrakis Chain "testcoin" with a single command: `hushd -ac_name=COIN ...`
If you are testing something that can run on one machine, run with the -regtest option.
In regression test mode, blocks can be created on-demand; see qa/rpc-tests/ for tests
that run in -regtest mode.
If you are testing something that can run on one machine you can use `-testnode=1`
which makes it so a single machine can create a new blockchain and mine blocks, i.e.
Duke
3 months ago