sikkienl/dash
1
0
Fork 0
mirror of https://github.com/dashpay/dash.git synced 2024-12-24 11:32:46 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity
Dash - Reinventing Cryptocurrency
25,480 Commits 24 Branches 554 Tags 573 MiB
C++ 52.7%
C 24.2%
Python 10.5%
Assembly 3.3%
JavaScript 2.6%
Other 6.5%
318c7263d0
Go to file
Wladimir J. van der Laan 318c7263d0
Merge #19522: build: fix building libconsensus with reduced exports for Darwin targets 
de4238f92f4c067f099663f68d9772105de81d75 build: consolidate reduced export checks (fanquake)
012bdec1b7df01906566a6526e56f27d57d1653b build: add building libconsensus to end-of-configure output (fanquake)
8f360e349e365870b40a6873917c81de714ae41a build: remove ax_gcc_func_attribute macro (fanquake)
f054a089ecfbdc4732e6f705a10e93189074f41c build: remove AX_GCC_FUNC_ATTRIBUTE test for dllimport (fanquake)
7cd0a696643a824ab6f6911278f116f01c5af662 build: test for __declspec(dllexport) in configure (fanquake)
1624e17b5430dfe808bb3b1b79dfa53bf45aa053 build: remove duplicate visibility attribute detection (fanquake)

Pull request description:

  Darwin targets do not have a `protected` visibility function attribute, see [LLVM explanation](8e9a505139/clang/lib/Basic/Targets/OSTargets.h (L131)). This means that the `AX_GCC_FUNC_ATTRIBUTE` check for `visibility` fails:
  ```bash
  configure:24513: checking for __attribute__((visibility))
  configure:24537: g++ -std=c++11 -o conftest -g -O2  -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS -DMAC_OSX -DOBJC_OLD_DISPATCH_PROTOTYPES=0  -Wl,-headerpad_max_install_names conftest.cpp  >&5
  conftest.cpp:35:56: warning: target does not support 'protected' visibility; using 'default' [-Wunsupported-visibility]
                      int foo_pro( void ) __attribute__((visibility("protected")));
                                                         ^
  1 warning generated.
  configure:24537: $? = 0
  configure:24550: result: no
  ```

  This leads to `EXPORT_SYMBOL` being [defined to nothing](f4de89edfa/src/script/bitcoinconsensus.h (L29)), as `HAVE_FUNC_ATTRIBUTE_VISIBILITY` is not defined, and when building with reduced exports, you end up with a libbitcoinconsensus.dylib that doesn't export any  `_bitcoinconsensus_*` symbols.
  ```bash
  ➜  git:(master) nm -C src/.libs/libbitcoinconsensus.dylib | rg _bitcoinconsensus_
  ➜  git:(master)
  ```

  We do have a [second check](f4de89edfa/configure.ac (L882)) for the `visibility` attribute, which works for Darwin as it's only testing for default visibility, however the result of this check isn't used at all. It was added in #4725, along with the `--enable-reduce-exports` option, however when libbitcoinconsensus was added in #5235, it used the results of the added `AX_GCC_FUNC_ATTRIBUTE` calls.

  This PR removes our usage of the AX_GCC_FUNC_ATTRIBUTE macro entirely, in favour of our own checks in configure. This meant adding a check for `dllexport`, which I've tested as working with both [GCC](https://gcc.gnu.org/onlinedocs/gcc/Microsoft-Windows-Function-Attributes.html) and [Clang](https://releases.llvm.org/10.0.0/tools/clang/docs/AttributeReference.html#dllexport) when building for Windows. I haven't added an equivalent check for `dllimport`, as we weren't actually using the result of that check, we're just testing that `MSC_VER` was defined before using.

  With these changes building a libbitcoinconsensus with reduced exports, when targeting Darwin, works as expected:
  ```bash
  ./autogen.sh
  ./configure --disable-tests --disable-bench --with-utils=no --with-daemon=no --with-gui=no --disable-wallet --with-libs=yes --enable-reduce-exports
  make -j8
  ...
  nm -C src/.libs/libbitcoinconsensus.dylib | rg _bitcoinconsensus_
  000000000000a340 T _bitcoinconsensus_verify_script
  00000000000097e0 T _bitcoinconsensus_verify_script_with_amount
  000000000000a3c0 T _bitcoinconsensus_version
  ```

  ```python
  >>> import ctypes
  >>> consensus = ctypes.CDLL("src/.libs/libbitcoinconsensus.dylib")
  >>> print(consensus.bitcoinconsensus_version())
  1
  >>> exit()
  ```

  TODO: Modify a CI job to compile with --enable-reduce-exports and check for symbols in shared lib?

ACKs for top commit:
  laanwj:
    Code review ACK de4238f92f4c067f099663f68d9772105de81d75

Tree-SHA512: d148f3c55d14dac6e9e5b718cc65bb557bcf6f663218d24bc9044b86281bd5dd3d931ebea79c336a58e8ed50d683218c0a9e75494f2267b91097665043e252ae
2024-04-11 02:25:06 +07:00
.github chore: narrow score of clang-diff-format for dash specific files only 2024-03-24 00:41:24 +07:00
.tx fix: follow-up #5393 - should be used [dash.dash_ents] (#5472) 2023-07-01 14:16:50 +03:00
build-aux/m4 Merge #19522: build: fix building libconsensus with reduced exports for Darwin targets 2024-04-11 02:25:06 +07:00
ci Merge #21138: ci: Re-run wine tests once if they fail 2024-04-11 02:25:06 +07:00
contrib guix: exclude debug symbols for apple from list of hash sums due to its undeterminism 2024-04-03 23:45:24 +07:00
depends fix: drop -static-libstc++ from depends/hosts/{linux,mingw32}.mk which is clang-only 2024-04-03 16:03:26 +07:00
doc Merge #21075: doc: Fix markdown formatting 2024-04-11 02:25:05 +07:00
share feat: Set client version for non-release binaries and version in guix based on git tags (#5653) 2024-01-11 21:43:42 -06:00
src Merge #19522: build: fix building libconsensus with reduced exports for Darwin targets 2024-04-11 02:25:06 +07:00
test feat: add option -usehd to wallettool to let create non-hd wallets 2024-04-10 01:59:00 +07:00
.cirrus.yml Merge #21126: ci: Properly bump to focal for win cross build 2024-04-11 02:25:06 +07:00
.dockerignore build: add dash minimal development environment container 2021-12-21 12:43:37 +05:30
.editorconfig Merge #21123: code style: Add EditorConfig file 2021-07-16 10:04:09 -05:00
.fuzzbuzz.yml Merge #21064: refactor: use std::shared_mutex & remove Boost Thread 2024-01-16 09:29:52 -06:00
.gitattributes Separate protocol versioning from clientversion 2014-10-29 00:24:40 -04:00
.gitignore merge bitcoin#21336: Make .gitignore ignore src/test/fuzz/fuzz.exe 2024-02-06 08:39:51 -06:00
.gitlab-ci.yml chore: increase amount of build jobs from 4 to 8 for depends 2024-03-17 01:09:41 +07:00
.python-version partial bitcoin#27483: Bump python minimum version to 3.8 2023-05-11 09:18:48 -05:00
.style.yapf Merge #15533: test: .style.yapf: Set column_limit=160 2021-07-10 12:10:51 -05:00
autogen.sh Merge #17829: scripted-diff: Bump copyright of files changed in 2019 2023-12-06 11:40:14 -06:00
CMakeLists.txt chore: Added missing sources files in CMake (#5503) 2023-07-25 12:23:56 -05:00
configure.ac Merge #19522: build: fix building libconsensus with reduced exports for Darwin targets 2024-04-11 02:25:06 +07:00
CONTRIBUTING.md Merge bitcoin/bitcoin#25165: doc: Explain squashing with merge commits 2024-02-22 20:58:44 -06:00
COPYING docs: update license year range to 2024 (#5890) 2024-02-22 20:56:43 -06:00
INSTALL.md Dashify INSTALL.md and build-unix.md 2018-01-12 16:12:54 +01:00
libdashconsensus.pc.in revert dash#1432: Rename consensus source library and API 2022-08-09 14:16:28 +05:30
Makefile.am Merge #20549: Support make src/bitcoin-node and src/bitcoin-gui 2024-01-16 09:34:27 -06:00
README.md Merge #20691: ci, doc: Travis CI features and mentions cleanup 2024-03-27 00:48:26 +07:00
SECURITY.md Merge bitcoin/bitcoin#23466: doc: Suggest keys.openpgp.org as keyserver in SECURITY.md 2022-04-03 18:46:47 -05:00

README.md

Dash Core staging tree

CI master develop
Gitlab Build Status Build Status

https://www.dash.org

For an immediately usable, binary version of the Dash Core software, see https://www.dash.org/downloads/.

Further information about Dash Core is available in the doc folder.

What is Dash?

Dash is an experimental digital currency that enables instant, private payments to anyone, anywhere in the world. Dash uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Dash Core is the name of the open source software which enables the use of this currency.

For more information read the original Dash whitepaper.

License

Dash Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.

Development Process

The master branch is meant to be stable. Development is normally done in separate branches. Tags are created to indicate new official, stable release versions of Dash Core.

The develop branch is regularly built (see doc/build-*.md for instructions) and tested, but is not guaranteed to be completely stable.

The contribution workflow is described in CONTRIBUTING.md and useful hints for developers can be found in doc/developer-notes.md.

Testing

Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.

Automated Testing

Developers are strongly encouraged to write unit tests for new code, and to submit new unit tests for old code. Unit tests can be compiled and run (assuming they weren't disabled in configure) with: make check. Further details on running and extending unit tests can be found in /src/test/README.md.

There are also regression and integration tests, written in Python. These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py

The CI (Continuous Integration) systems make sure that every pull request is built for Windows, Linux, and macOS, and that unit/sanity tests are run automatically.

Manual Quality Assurance (QA) Testing

Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.

Translations

Changes to translations as well as new translations can be submitted to Dash Core's Transifex page.

Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.

Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.