Current build of native library breaks version on Maven Central

[thunderbiscuit]

Because of the new API (txid). This threw me in for a loop today but it finally clicked. The error I was getting was just so completely unrelated that it took me a while to figure it out.

So for now if you're pulling the library from Maven Central (0.1.2), you need to build the native lib on a detached head state at commit e2269f759a16db388e87fc9f589bca0cc9d050d3.

[thunderbiscuit]

Low cost solution to this right now (until we can ship the fat jars or whatever comes with the native libs embedded) would be to create a tag for each Maven Central release, and just let people know in the readme. "Whatever version is in your dependencies you should pull that tag and build the native library version for that particular release" type of thing.

Just because the latest version on master is likely to always have some sort of breaking change from the dependency specified in the gradle build file.

[notmandatory]

The .jar and .aar on maven central should already include the required rust binaries. Maybe you need to clear your build env?

Anyway you're right that I should have tagged the commit I used to create the build for the maven central release, it is b390a95ae, I pushed one now called v0.1.2.

[thunderbiscuit]

Thanks! I didn't know it was included. That helps because now I understand where the issue is coming from: it's only there for the linux-x86-64 architecture.

❯ jar xf bdk-jvm-0.1.2.jar

❯ tree
.
├── bdk-jvm-0.1.2.jar
├── linux-x86-64
│  └── libbdkffi.so
├── META-INF
│  ├── jvm.kotlin_module
│  └── MANIFEST.MF
└── org
   └── bitcoindevkit
      ├── _UniFFILib$Companion$INSTANCE$2.class
      ├── _UniFFILib$Companion.class
      ├── ...

Which makes perfect sense given the error I get when I try to run the app:

Native library (darwin-x86-64/libbdkffi.dylib) not found in resource path (
    /Users/user/sandbox/tinywallet-temp/app/build/install/app/lib/app.jar:
    /Users/user/sandbox/tinywallet-temp/app/build/install/app/lib/bdk-jvm-0.1.2.jar:
    /Users/user/sandbox/tinywallet-temp/app/build/install/app/lib/clikt-jvm-3.3.0.jar:
    /Users/user/sandbox/tinywallet-temp/app/build/install/app/lib/kotlin-stdlib-jdk8-1.5.31.jar:
    ...

Now the question come back to #76... how many and which native libs can we provide without making a 700MB mega library... For the moment at least, I suggest we add "on demand" (at least to start), and so that would include the darwin-86-64 for me (I have the M1 chip but it runs the JVM in an emulator so it's looking for x86_64 native libraries). Related to this is the fact that I don't think we're currently building the release version of the libraries (libbdkffi.so is 119MB in bdk-jvm-0.1.2), which are much smaller (see bitcoindevkit/bdk-jni#49).

[notmandatory]

We can certainly make the rust libs smaller by building them in release mode. And we have issue #76 to include libs for more target. I'd like to be able to include at least the linux x86_64, darwin x86_64 and aarch64, and win x86 targets in our .jar builds. If the release builds are small enough we could include others, next on my list would be linux aarch64 (used on some small single board computers).

[thunderbiscuit]

Mind if I make a PR for this? I think what happened with 0.1.2 is probably that it was built on a Linux machine, and the way we have it setup in the build.sh file, it only adds the library on your development machine. Shouldn't be too hard to ensure we build and add a few architectures, no matter the building machine.

Edit: I tried building a script that would build for a few different architectures and simply bring those in the library, but it appears I can't build on my machine some of the other targets:

  cargo build --release --target x86_64-apple-darwin 
  cargo build --release --target x86_64-unknown-linux-gnu
  cargo build --release --target x86_64-pc-windows-gnu

Only the first one builds without errors for me. How would one go about building for a few different architectures all in one go?

[thunderbiscuit]

I think this is really more a discussion for #76. Closing now.