- re-enable Nim's cache globally
- add a new "nimcache" subdir for the libraries
- make sure Go doesn't try to link libnimbus.a in the dynamically linked
wrapper example
- always delete the static archive before recreating it
- rename wrapper.nim/.h to libnimbus.nim/.h
- better hygiene in libnimbus.h (include guards and C++ support)
- remove MainnetBootnodes copy, since we do include "config.nim" after all
- moved "nimbus/api" to "wrappers"
- renamed files
- replaced the build scripts with Makefile targets
- set the rpath relative to the test binary's location so it can look
for libnimbus.so there at runtime
- libnimbus.so.0 required on Linux, apparently
- compiled all the Nimbus code with `--app:lib`, not just one file (this
required skipping a proc in "nimbus/config.nim" because it uses an API
that's unavailable in libraries)
- removed static linking from the Go wrapper. It doesn't make sense at a
global level, when using a shared Nimbus library. To selectively link
static libraries, we should probably be specifying them as *.a. I did
build a static libnimbus.a, as a test, but it insisted on dlopen-ing a
shared version of itself which looked too ugly to continue.
* dummy c lib
* go stuffz
* Compile secp
* Compile as shared library
* Build with debug info
* Prelude exposed fns with setupForeignThreadGc() (naive)
To avoid GC/thread issues causing segmentation fault when running from Go.
* Add logging, fix lib path and gomaxprocs to make debuggable
* lock to os thread
* Address basic feedback and mark TODOs
* Use normal secp (shared lib flow now)
* api: cleanup, move to api folder
addSignal() doesn't seem to work, which is probably why it was commented
out. I'm using setControlCHook() instead, moved at an earlier point in the
start-up process, but its handler can only change global variables, so I
had to make "nimbus" global.
Ștefan Talpalaru
Zahary Karadjov
Bruno Škvorc
Jacek Sieka
kdeme