dev branch: cp: *.so: No such file or directory
Closed this issue · 7 comments
I managed to patch Armory to run through to the install phase which breaks with the message from the subject.
Log: https://people.freebsd.org/~yuri/bitcoin-armory-0.96.5.20210412.log
I would like to restore the Armory FreeBSD port that was removed in 2019 because it used removed Qt4.
Ah, that's part of the build system I haven't gone over yet. Armory used to expose a C++ lib to python using SWIG, that's the *.so copy at install time.
I changed the design as part of the migration to py3/qt5 to create a binary that talks to python over an encrypted socket. I haven't fixed the install phase at all. If you want to revive the freeBSD port, keep in mind that the dev branch is still WIP. Also I'll probably have to fix all these compilation warnings as well.
@goatpig
Please let me know when something would be ready to test and maybe to revive the FreeBSD port.
There is a tentative cmake build system now, merged into dev yesterday. I still recommend using autotools for now. I haven't updated the readme for build instructions. This is still in flux, but you should get a lot further now.
- cmake is setup to look for system lws and libbtc. You can clone libbtc locally, build it and feed it to cmake via -DWITH_LIBBTC=custom path if your system doesn't have libbtc package.
- autotools requires a custom path for both lws and libbtc. You need to clone both repos for these dependencies, build them yourself, then point to the repo path via --with-own-lws=path and --with-own-libbtc=path.
- While autotools requires more hand holding, it generates lib files for 2 dependencies (hkdf and chachapoly) that are required to build the c20poly1305 python module. This is a one time thing but it needs done for ArmoryQt.py to run. You have to run "python c20poly1305.py --libbtc_path=path" in the c20poly1305 folder once to generate the module.
- I have to update the cmake build to generate those libs instead of building the code straight into binaries.
- The c20poly1305 module dynamically links to libbtc, and looks for the lib using rpath. I haven't figured out how to statically link it yet (it wants libbtc built with -fPIC and that would mean modifying the libbtc build system).
- I have to figure out how to detect system lws and libbtc with autotools
- I have to automate the generation of the c20p1305 python module from the build system, maybe package it in a pip even.
Once you've completed all these steps, you should have a functional build on linux. If you're looking to build on windows, you're left with the cmake build and battling the dependencies. I haven't worked on that yet.
Did it become easier to build with cmake since January?
I tried but it fails:
CMake Error at CMakeLists.txt:30 (MESSAGE):
Could not find LMDB lib
lmdb doesn't provide cmake scripts.
GNU build also fails: it fails to find the external libsecp256k1 despite the pkgconfig file being present: /usr/local/libdata/pkgconfig/libsecp256k1.pc:
gmake[4]: Entering directory '/disk-samsung/freebsd-ports/finance/bitcoin-armory/work/BitcoinArmory-3498bd8/cppForSwig'
gmake[4]: *** No rule to make target '/usr/local/lib/src/secp256k1/libsecp256k1.la', needed by 'libArmoryWallets.la'. Stop.
The build should use libsecp256k1.pc when present.
It uses system LMDB now
The cmake build went through, but it installed only these 2 files:
bin/BIP150KeyManager
bin/armorydb