Build failure on FreeBSD

[nkosi23]

Describe the bug
When building the full service API on FreeBSD, everything builds smoothly until the 798th package out of 924, the build error is:

To Reproduce
Steps to reproduce the behavior:

Install rustup on FreeBSD as explained in: https://gist.github.com/fabiotatsuo/e88b025baf3dfa47683419948723706f

Install the build dependencies with the command:

pkg install cmake protobuf llvm llvm-devel sqlite3 sqlcipher git bash

Expected behavior
The build completes without error. Rusts binaries are usually easily portable to FreeBSD, it looks like this issue could just be a matter of adding a few config files to support FreeBSD.

Environment (please complete the following information):

• OS: FreeBSD
• Version 13

Logs

error: failed to run custom build command for `hidapi v2.4.1`

Caused by:
  process didn't exit successfully: `/home/mobilecoin/full-service/target/release/build/hidapi-0f1b6d5217db2a16/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=HIDAPI_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-freebsd
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_freebsd
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=HIDAPI_STATIC
  cargo:rerun-if-env-changed=HIDAPI_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-freebsd
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_freebsd
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-freebsd
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_freebsd
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-freebsd
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_freebsd
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=HIDAPI_STATIC
  cargo:rerun-if-env-changed=HIDAPI_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-freebsd
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_freebsd
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-freebsd
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_freebsd
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-freebsd
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_freebsd
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hidapi-2.4.1/build.rs:131:41:
  Unable to find hidapi: Could not run `PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 pkg-config --libs --cflags hidapi`
  The pkg-config command could not be found.

  Most likely, you need to install a pkg-config package for your OS.
  Try `apt install pkg-config`, or `yum install pkg-config`,
  or `pkg install pkg-config`, or `apk add pkgconfig` depending on your distribution.

  If you've already installed it, ensure the pkg-config command is one of the
  directories in the PATH environment variable.

  If you did not expect this build to link to a pre-installed system library,
  then check documentation of the hidapi crate for an option to
  build the library from source, or disable features or dependencies
  that require pkg-config.
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

And the build eventually ends with these logs.

Additional context
Add any other context about the problem here.

[nick-mobilecoin]

if you want FreeBSD native you might be able to get by using https://github.com/mobilecoinofficial/full-service/blob/main/tools/build-fs.sh

./tools/build-fs.sh main

The error your getting is because the enclave css(not cascading style sheets) environment variables are not specified via:

• CONSENSUS_ENCLAVE_CSS
• INGETS_ENCLAVE_CSS

When these aren't specified then the build tries to build the enclaves to generate the css files.
However the enclave builds are limited to x86_64 linux.

The build-fs.sh will download the current css files for you and then build full service using them.

you could also use the docker image. The mob command will invoke docker for the appropriate image.

./mob prompt
cargo build

[nkosi23]

@nick-mobilecoin Thanks a lot for your swift reply! However I was actually using the build-fs.sh script, here is the full output of the terminal session (but you helped me find out the actual issue):

root@mobilecoinfullservicetest:/home/mobilecoin/full-service/tools # ./build-fs.sh test
/root/.cargo/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
/bin/csh
Setting 'test' SGX, IAS and enclave values
  IAS_MODE: PROD
  SGX_MODE: HW
  CONSENSUS_ENCLAVE_CSS: /home/mobilecoin/full-service/target/release/consensus-enclave.css
  INGEST_ENCLAVE_CSS: /home/mobilecoin/full-service/target/release/ingest-enclave.css
building full service...
   Compiling typenum v1.17.0
   Compiling clang-sys v1.7.0
   Compiling protobuf v2.28.0
   Compiling mc-util-build-info v6.0.0 (/home/mobilecoin/full-service/mobilecoin/util/build/info)
   Compiling num-bigint v0.4.4
   Compiling crunchy v0.2.2
   Compiling hidapi v2.4.1
error: failed to run custom build command for `hidapi v2.4.1`

Caused by:
  process didn't exit successfully: `/home/mobilecoin/full-service/target/release/build/hidapi-0f1b6d5217db2a16/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=HIDAPI_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-freebsd
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_freebsd
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=HIDAPI_STATIC
  cargo:rerun-if-env-changed=HIDAPI_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-freebsd
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_freebsd
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-freebsd
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_freebsd
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-freebsd
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_freebsd
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=HIDAPI_STATIC
  cargo:rerun-if-env-changed=HIDAPI_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-freebsd
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_freebsd
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-freebsd
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_freebsd
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-freebsd
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_freebsd
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hidapi-2.4.1/build.rs:131:41:
  Unable to find hidapi: Could not run `PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 pkg-config --libs --cflags hidapi`
  The pkg-config command could not be found.

  Most likely, you need to install a pkg-config package for your OS.
  Try `apt install pkg-config`, or `yum install pkg-config`,
  or `pkg install pkg-config`, or `apk add pkgconfig` depending on your distribution.

  If you've already installed it, ensure the pkg-config command is one of the
  directories in the PATH environment variable.

  If you did not expect this build to link to a pre-installed system library,
  then check documentation of the hidapi crate for an option to
  build the library from source, or disable features or dependencies
  that require pkg-config.
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

Well, when posting this message, I noticed that the actual error is that I hadn't installed the pkg-config package (pkgconf on FreeBSD) and the hidapi package.

But I am now hitting this build error when building the package 820ish out of 924 (nearly there!!!):

 Compiling mc-util-parse v6.0.0 (/home/mobilecoin/full-service/mobilecoin/util/parse)
error[E0432]: unresolved import `crate::platform::PeripheralId`
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btleplug-0.10.5/src/api/mod.rs:44:5
   |
44 | use crate::platform::PeripheralId;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `PeripheralId` in `platform`
   |
note: found an item that was configured out
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btleplug-0.10.5/src/platform.rs:6:77
   |
6  |     adapter::Adapter, manager::Manager, peripheral::Peripheral, peripheral::PeripheralId,
   |                                                                             ^^^^^^^^^^^^
   = note: the item is gated behind the `linux` feature
note: found an item that was configured out
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btleplug-0.10.5/src/platform.rs:10:77
   |
10 |     adapter::Adapter, manager::Manager, peripheral::Peripheral, peripheral::PeripheralId,
   |                                                                             ^^^^^^^^^^^^
note: found an item that was configured out
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btleplug-0.10.5/src/platform.rs:14:83
   |
14 |     adapter::Adapter, init, manager::Manager, peripheral::Peripheral, peripheral::PeripheralId,
   |                                                                                   ^^^^^^^^^^^^
   = note: the item is gated behind the `android` feature
note: found an item that was configured out
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btleplug-0.10.5/src/platform.rs:18:77
   |
18 |     adapter::Adapter, manager::Manager, peripheral::Peripheral, peripheral::PeripheralId,
   |                                                                             ^^^^^^^^^^^^
   = note: the item is gated behind the `windows` feature

error[E0432]: unresolved import `crate::platform::PeripheralId`
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btleplug-0.10.5/src/common/adapter_manager.rs:15:5
   |
15 | use crate::platform::PeripheralId;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `PeripheralId` in `platform`
   |
note: found an item that was configured out
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btleplug-0.10.5/src/platform.rs:6:77
   |
6  |     adapter::Adapter, manager::Manager, peripheral::Peripheral, peripheral::PeripheralId,
   |                                                                             ^^^^^^^^^^^^
   = note: the item is gated behind the `linux` feature
note: found an item that was configured out
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btleplug-0.10.5/src/platform.rs:10:77
   |
10 |     adapter::Adapter, manager::Manager, peripheral::Peripheral, peripheral::PeripheralId,
   |                                                                             ^^^^^^^^^^^^
note: found an item that was configured out
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btleplug-0.10.5/src/platform.rs:14:83
   |
14 |     adapter::Adapter, init, manager::Manager, peripheral::Peripheral, peripheral::PeripheralId,
   |                                                                                   ^^^^^^^^^^^^
   = note: the item is gated behind the `android` feature
note: found an item that was configured out
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btleplug-0.10.5/src/platform.rs:18:77
   |
18 |     adapter::Adapter, manager::Manager, peripheral::Peripheral, peripheral::PeripheralId,
   |                                                                             ^^^^^^^^^^^^
   = note: the item is gated behind the `windows` feature

error[E0412]: cannot find type `Adapter` in this scope
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btleplug-0.10.5/src/platform.rs:29:18
   |
29 | assert_impl_all!(Adapter: Central, Clone, Debug, Send, Sized, Sync);
   |                  ^^^^^^^ not found in this scope

error[E0412]: cannot find type `Manager` in this scope
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btleplug-0.10.5/src/platform.rs:30:18
   |
30 | assert_impl_all!(Manager: api::Manager, Clone, Debug, Send, Sized, Sync);
   |                  ^^^^^^^ not found in this scope
   |
help: consider importing this trait
   |
21 + use crate::api::Manager;
   |

error[E0412]: cannot find type `Peripheral` in this scope
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btleplug-0.10.5/src/platform.rs:31:18
   |
31 | assert_impl_all!(Peripheral: api::Peripheral, Clone, Debug, Send, Sized, Sync);
   |                  ^^^^^^^^^^ not found in this scope
   |
help: consider importing this trait
   |
21 + use crate::api::Peripheral;
   |

error[E0412]: cannot find type `PeripheralId` in this scope
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btleplug-0.10.5/src/platform.rs:33:5
   |
33 |     PeripheralId: Clone,
   |     ^^^^^^^^^^^^ not found in this scope

PS: Docker is not portable to FreeBSD so building from source is the only option we've got I'm afraid.

[nkosi23]

Here is the output of rustup show:

root@mobilecoinfullservicetest:/home/mobilecoin/full-service/tools # rustup show
Default host: x86_64-unknown-freebsd
rustup home:  /root/.rustup

installed toolchains
--------------------

stable-x86_64-unknown-freebsd
nightly-2023-10-01-x86_64-unknown-freebsd
nightly-x86_64-unknown-freebsd (default)

active toolchain
----------------

nightly-2023-10-01-x86_64-unknown-freebsd (overridden by '/home/mobilecoin/full-service/rust-toolchain')
rustc 1.74.0-nightly (ca62d2c44 2023-09-30)

I am not a rust developer so I know very little about this ecosystem and what could cause the issue, but my guess is that the toolchain i use may be lacking capabilities.

[nkosi23]

Okay the issue is apparently in the platform.rs file of btleplug, there is no definition for the FreeBSD OS. I will try to submit a PR:

#[cfg(target_os = "linux")]
pub use crate::bluez::{
    adapter::Adapter, manager::Manager, peripheral::Peripheral, peripheral::PeripheralId,
};
#[cfg(any(target_os = "macos", target_os = "ios"))]
pub use crate::corebluetooth::{
    adapter::Adapter, manager::Manager, peripheral::Peripheral, peripheral::PeripheralId,
};
#[cfg(target_os = "android")]
pub use crate::droidplug::{
    adapter::Adapter, init, manager::Manager, peripheral::Peripheral, peripheral::PeripheralId,
};
#[cfg(target_os = "windows")]
pub use crate::winrtble::{
    adapter::Adapter, manager::Manager, peripheral::Peripheral, peripheral::PeripheralId,
};

[nkosi23]

I have just submitted a PR containing a quick monkey patch to add a dummy FreeBSD definition reusing the crate for linux, which is guaranteed to cause a runtime error since FreeBSD's bluetooth stack is totally different.

But I'm crossing my fingers that no bluetooth capability is actually used, because this begs the question, why in the world does the full service API has a dependency on btleplug to start with? 😕

There are very little chances that my ridiculous PR is going to be approved upstream now that I think about it 😆 But applying this patch downstream is not going to be trivial as the rust toolchain downloads and builds crates automatically, I'd have to fiddle quite a bit to get going with the rust toolchain (edit: eventually came across patch-crate as I was digging into the source code and posting these messages). Even then, understanding how btleplug is being used by the full service API would be of the essence to ensure that this endeavour is even worth it (for if the package actually plays a critical role, then my workaround would not work).

The alternative and right approach would be to write proper upstream adapters for FreeBSD for btleplug, but this would require me to first learn the bluetooth spec, and then learn the bluetooth stack of FreeBSD. Oh and crash learn rust programming basics. One month of work at least 😢 Hopefully someone will reply that this package is being imported by mistake 😄

[nkosi23]

Okay, progressing as I get my feet wet on the rust toolchain, the culprit is apparently ledger-lib, as per cargo tree see the last 10 lines:

── ledger-mob v0.16.0 (/home/mobilecoin/full-service/ledger-mob/lib)
│   ├── anyhow v1.0.79
│   ├── async-trait v0.1.77 (proc-macro) (*)
│   ├── base64 v0.21.7
│   ├── clap v4.4.18 (*)
│   ├── ed25519-dalek v2.1.0 (*)
│   ├── encdec v0.9.0
│   │   ├── encdec-base v0.9.0
│   │   │   ├── byteorder v1.5.0
│   │   │   ├── heapless v0.7.17
│   │   │   │   ├── hash32 v0.2.1
│   │   │   │   │   └── byteorder v1.5.0
│   │   │   │   ├── spin v0.9.8
│   │   │   │   │   └── lock_api v0.4.11 (*)
│   │   │   │   └── stable_deref_trait v1.2.0
│   │   │   │   [build-dependencies]
│   │   │   │   └── rustc_version v0.4.0 (*)
│   │   │   ├── num-traits v0.2.17 (*)
│   │   │   └── thiserror v1.0.56
│   │   │       └── thiserror-impl v1.0.56 (proc-macro)
│   │   │           ├── proc-macro2 v1.0.78 (*)
│   │   │           ├── quote v1.0.35 (*)
│   │   │           └── syn v2.0.48 (*)
│   │   └── encdec-macros v0.9.0 (proc-macro)
│   │       ├── darling v0.14.4
│   │       │   ├── darling_core v0.14.4
│   │       │   │   ├── fnv v1.0.7
│   │       │   │   ├── ident_case v1.0.1
│   │       │   │   ├── proc-macro2 v1.0.78 (*)
│   │       │   │   ├── quote v1.0.35 (*)
│   │       │   │   ├── strsim v0.10.0
│   │       │   │   └── syn v1.0.109
│   │       │   │       ├── proc-macro2 v1.0.78 (*)
│   │       │   │       ├── quote v1.0.35 (*)
│   │       │   │       └── unicode-ident v1.0.12
│   │       │   └── darling_macro v0.14.4 (proc-macro)
│   │       │       ├── darling_core v0.14.4 (*)
│   │       │       ├── quote v1.0.35 (*)
│   │       │       └── syn v1.0.109 (*)
│   │       ├── encdec-base v0.8.3
│   │       │   ├── byteorder v1.5.0
│   │       │   └── num-traits v0.2.17 (*)
│   │       ├── proc-macro2 v1.0.78 (*)
│   │       ├── quote v1.0.35 (*)
│   │       └── syn v1.0.109 (*)
│   ├── futures v0.3.30
│   │   ├── futures-channel v0.3.30 (*)
│   │   ├── futures-core v0.3.30
│   │   ├── futures-executor v0.3.30 (*)
│   │   ├── futures-io v0.3.30
│   │   ├── futures-sink v0.3.30
│   │   ├── futures-task v0.3.30
│   │   └── futures-util v0.3.30 (*)
│   ├── hex v0.4.3 (*)
│   ├── lazy_static v1.4.0
│   │   └── spin v0.5.2
│   ├── ledger-lib v0.1.0
│   │   ├── async-trait v0.1.77 (proc-macro) (*)
│   │   ├── btleplug v0.10.5
│   │   │   ├── async-trait v0.1.77 (proc-macro) (*)
│   │   │   ├── bitflags v1.3.2
│   │   │   ├── dashmap v5.5.3
│   │   │   │   ├── cfg-if v1.0.0
│   │   │   │   ├── hashbrown v0.14.3 (*)

And the btleplug dependency looks quite central to what this library is doing 😞 :

A rust-based library for interacting with Ledger hardware wallets. This provides low-level USB/HID, BLE, and TCP/Speculos Transports as well as a high level LedgerProvider interface that manages device connections using a pinned worker thread for use from async / tokio contexts.

Why is this library needed by the full service API? Any chance to put it behind a platform-specific compile flag (using the [cfg(target_os = "linux")] attribute)?

Maybe the build of ledger-mob itself could be put behind an OS flag since apparently it is specific to Ledger's hardware so I am not sure why including it in the full-service API is even relevant:

A MobileCoin NanoApp for Ledger nanosplus and nanox devices. You can grab the latest (unsigned) firmware and tooling here, or follow the Getting Started instructions to build your own.

[nick-mobilecoin]

Any chance to put it behind a platform-specific compile flag

I did a little digging around, it looks like the ledger logic is spread around a bit in the code base.
So it would likely take a bit to isolate the ledger code.

My vote would be that it goes behind a feature flag maybe something like hw_signing or similar.
Unfortunately I don't think this will get prioritized from our end at this time.

[nkosi23]

Oh sad to hear that. As a gentle feedback, working on adding mobilecoin support to our non-crypto-focused product has been constantly pushed back due to perceived and now real cans of worms.

Initially, based on the documentation, we assumed that it was not possible to build the full-service API without having an intel processor and the SGX libraries installed. Since we exclusively use FreeBSD for our workloads, and AMD processors, needless to say that we weren't very eager to get into this 🥲 I was surprised when it turned out that the build actually worked fine without SGX for the reason you explained.

Now this ledger thing will be the actual show stopper. I guess the "easiest" course of action for us would be to provision a linux VM somewhere, which is not totally trivial as it also has implications on things like sysadmin (we'll now have 2 operating systems to run, update, secure, backup etc...). In our case, we can't use bhyve (FreeBSD's virtualizer allowing one to run VM's as easily as jails hosted by a FreeBSD host) which would have made things easier but our FreeBSD hosts are already running virtualized under a KVM managed by our hosting partner.

[nkosi23]

My vote would be that it goes behind a feature flag maybe something like hw_signing or similar.
Unfortunately I don't think this will get prioritized from our end at this time.

I am not in a position to commit to working on it right now but to have visibility: would you welcome a PR isolating the ledger code, or would you prefer the core team to handle it itself (for example because there'd be too many implications on design, architecture etc...)

[holtzman]

as a quick experiment, would you see if the experiment/no-hardware-wallet branch builds on freebsd? It's building on MacOS sans the ledger-mob submodule, though I haven't really tested it.

As Nick said, it would be hard for us to prioritize refactoring things right now, so just gathering data...

[nkosi23]

@holtzman Many thanks for the experiment,

I am hitting a panic when building the grpcio-sys crate so I have opened an issue in their repo. However since this happens when building the crate 851 out 890, I have a sense that the rest of the build will work fine once the issue with grpc is addressed upstream.

The way you isolated ledger seems to work, but I'll need to run it to confirm this once the build issue is fixed.

[holtzman]

@nkosi23 I have removed the bug label as full-service is not supported for freebsd.