Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
add breez-sdk-go and link it correctly for linux
macOS, Windows, Android to follow in later commits.
```
go get github.com/breez/breez-sdk-go
go mod tidy
go mod vendor
```
By naively adding breez-sdk-go, it adds a absolute rpath to the Go
executable (in case of `make servewallet`) or the Go
libraries (libserver.so), due to the absolute path here:
```
cgo linux,amd64 LDFLAGS: -Wl,-rpath,${SRCDIR}/lib/linux-amd64 #-L${SRCDIR}/lib/linux-amd64
```
(https://github.com/breez/breez-sdk-go/blob/7b566724daae0fa539f622b301fe840a3e5cbd59/breez_sdk/cgo.go)
`SRCDIR` is an absolute path and it ends up in the libserver.so binary:
```
$ readelf -d frontends/qt/server/libserver.so
Dynamic section at offset 0xe7d810 contains 32 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [librt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libresolv.so.2]
0x0000000000000001 (NEEDED) Shared library: [libbreez_sdk_bindings.so]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000010 (SYMBOLIC) 0x0
0x000000000000001d (RUNPATH) Library runpath: [/opt/go/src/github.com/digitalbitbox/bitbox-wallet-app/vendor/github.com/breez/breez-sdk-go/breez_sdk/lib/linux-amd64]
```
This is good so that `make servewallet` runs out of the box, but bad
because the absolute path ends up in libserver.so as well.
This way the libbreez_sdk_bindings.so could not be found by a deployed
BitBoxApp, as this folder generally does not exist. We have to instead
copy the breez library to the BitBox folder and fix the library
resolution.
To do this, we move both libs to the `./lib` folder relative to the
`BitBoxApp`, where all shared libs reside. `linuxdeployqt` already
handles libraries in the `./lib` directory and rewires their rpaths
and adds `rpath=$ORIGIN/lib` to the `BitBox` executable, so we put the
libserver.so and libbreez_sdk_bindings.so there
instead. `linuxdeployqt` then fixes its rpath:
```
readelf -d lib/libserver.so
Dynamic section at offset 0xe7d810 contains 32 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [librt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libresolv.so.2]
0x0000000000000001 (NEEDED) Shared library: [libbreez_sdk_bindings.so]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000010 (SYMBOLIC) 0x0
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN]
```
In BitBox.pro, we can then remove `$ORIGIN` from the rpath of the
`BitBox` executable, as libsever.so is not in the same folder anymore,
so it is not needed anymore.
Checking the rpath in libbreez_sdk_bindings.so:
```
readelf -d lib/libbreez_sdk_bindings.so
[...]
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN:$ORIGIN/../../../../../../../../.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib]
```
This is a strange relative path that is not needed (if deleted with
`chrpath --delete lib/libbreez_sdk_bindings.so` the app works
fine). We could delete this manually in a later commit.
A note about open-source: https://github.com/breez/breez-sdk-go is a
thin wrapper around https://github.com/breez/breez-sdk-go, which
vendors the shared libary binaries compiled from the Breez SDK. This
is not ideal, but in the end, all libraries are open source and users
can replace the shared libraries with their own compiled binaries. In
the future we could look into building the shared libararies as part
of the BitBoxApp build process.- Loading branch information
