.exe files are for windows only. Linux systems do not use the same file extension or file type as windows. I assume you just want to create a Linux binary that can be used on all systems without installing all dependencies. To do that, you can use Bitcoin Core's depends system. Instructions are here: https://github.com/bitcoin/bitcoin/tree/master/depends.
Since the build system has moved to Autotools, the method for building Bitcoin-Qt is a bit different.
git clone https://github.com/bitcoin/bitcoin.git bitcoin
git checkout v0.8.5
If you got the source via git, you can checkout on the latest stable release tag, currently v0.8.1 using the git command git checkout v0.8.1.
When you did not setup git, you can simply download the source from that tag version from the webpage you suggested using either the .zip or .tar.gz link underneath the tag name. vX.X.X releases are stable ones, while ...
I've done a rebuild of 0.20.1 and I get the same results that you do. This would indicate that a build dependency has updated to produce slightly different results than the version that was in use at the time of the release. The build dependency versions are pinned unlike the actual software dependencies. IIRC this is common for gitian builds and attempting ...
Initial compiling of bitcoin-core can take a couple of minutes. If you have a multicore processor, you can use make -j<cores+1> to speed up compiling (parallel compiling).
Once bitcoin-core is compiled, a single semicolon change does (mostly) not require to recompile everything. You only compile the affected files (.cpp) again and do do the linking.
Since this is the first result that pops up on google when searching "bitcoin windows depends build" and the user asked how to build the .exe (but was actually looking for static build instructions on ubuntu) the correct instructions would be to use cross compilation with the depends system as specified in the documentation here: https://github.com/bitcoin/...
Because checking for compiler features, without Automake/CMake/Ninja/Bazel with only Makefile and C++ preprocessor is hard and unelegant.
And C++ preprocessor can't be used to make full-compile feature tests. If the compiler supports AVX256, a relatively new instruction set, that doesn't mean the assembler supports it too. There are "fail if can't ...
The build system has changed to autotools in later versions of Litecoin.
The process now looks like this:
make install # optional
There's up to date instructions in detail in build-unix.md.
The build_unix directory contains just the .IGNORE_ME file in the distribution. The directory is populated by the make command.
../dist/configure --disable-replication --enable-mingw --enable-cxx
You do not need to edit db.h in the latest distribution since they have already corrected the typedef.
You will have to rebuild OpenSSL, since the build shipped by Fedora/Red Hat does not include support for elliptic curve cryptography, on which Bitcoin relies. So you have to build your own.
Once that's done, you can get on with building Bitcoin normally, provided you point it at your private build of OpenSSL with -rpath.
Or, you can just skip all the work ...
On a Mac Pro with MacOS Sierra 10.12.6 I got a clean compilation by following the instructions in doc/build-osx.md.
The sequence of commands is:
1) First install Xcode and HomeBrew by executing (in Terminal)
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" < /dev/null 2> /dev/null
if you can compile your node, do it. well done! for most of the users it is technically nearly impossible to compile a bitcoin node because most of people have not enough technical knowledge. bitcoin.org provides binaries so that all people (who have not the time and knowledge to compile it) can also run a node.
hint: if you want to be 100% sure that you ...
By default, yes and no.
No, most of the code is compiled for generic target hardware. If you want something optimized for your actual hardware, you can add -march=native to your compilation flags (e.g. you'd run ./configure CFLAGS="-march=native" CXXFLAGS="-march=native"). This will result in a binary that may not work on other hardware ...
Like it says, you are missing the header file miniupnpc/miniwget.h. Usually this means there is a required library that is not installed.
Ubuntu has the convenient tool apt-file for finding which package provides a particular file. Install the apt-file package (apt-get install apt-file) and run apt-file update to install the file list. Then you can do
somehow or another, I got this to compile. it was some combination of:
install libboost1.48-all-dev libdb++-dev
then install without version number
then compile, compile fails
install without version number
I don't remember, but it seemed random.
If I knew for a fact the correct ...
I am not sure StackExchange is the place to ask this as it's issue level (which GitHub can take care of - https://github.com/stellar/stellar-core/issues).
Anyways, in the Install-Windows.txt it says to also update your PATH environment variable, did you do this?
Libraries should be installed in /usr/include.
For Boost, the path to it should be /usr/include/boost. That's where the linker would be looking for the libraries.
Otherwise, you may elect to install the libraries in some different directory and symlink it to /usr/include anyways.
The standard compile process does not static "include" dependencies in the executable file. It refers to the installed libdb, boost, etc.
This (dynamic linkes libraries) is an efficient concept. Otherwise each executable that uses – as example – boost would require to include the whole boost dependency in the binary.
The "official" Bitcoin-Core binaries ...
An alternative solution would be to build a tarball archive like the one you can download from the Bitcoin Core website.
To do that you have to follow the release process, as explained in:
The process actually consists in creating a Gitian build:
You can use the gitian build system. Instructions for building 0.8.x with gitian are available here: https://github.com/bitcoin/bitcoin/tree/0.8/contrib/gitian-descriptors and here: https://github.com/bitcoin/bitcoin/blob/0.8/doc/release-process.md. Using gitian should get you exactly the same binaries as those that were released.
This means your file has DOS newlines thus, hidden CR characters at the end.
Thus, set -e becomes set -e$'\r' (using bash-specific syntax to represent the CR character), which isn't a valid option.
To fix this, if you have dos2unix installed, you can run:
As you can see here the latest version is now the more stable version. As the most recent changes are for bug fixes, etc.
This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.
If you download a previous version this version may contain those fixed bugs.
The Bitcoin Core source code is in a git repository. The repository has multiple branches and tags. The branches are source trees for a major version (e.g. 0.14 releases) and tags are for individual releases.
If you want to use the latest stable version of Bitcoin Core, run the following command:
git checkout v0.14.2
If you want to use the latest source ...
The "51bad91" may be a bit misleading here, it's just coincidence that it says "bad". It's actually just the most recent commit on the 0.15 branch, https://github.com/bitcoin/bitcoin/commit/51bad9195eb435200626beccbaf6b60774a4a894
The -dirty suffix is added during the build here: