[ThatGeoGuy]

This is in follow-up to my previous PR #686. That PR was broken from the get-go, because it attempts to statically link every TCTI in the build script.

I didn't notice it at the time when I tested that PR, because I was using mold as my linker, which is a little more permissive in terms of the "duplicate symbols" errors that I was getting versus rust-lld. Example:

= note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: rust-lld: error: duplicate symbol: Tss2_Tcti_Info
          >>> defined at tcti-device.c:544 (/builds/.../target/release-with-debug/build/tss-esapi-sys-6480e311b983e39c/out/tpm2-tss/src/tss2-tcti/tcti-device.c:544)
          >>>            tcti-device.o:(Tss2_Tcti_Info) in archive /builds/.../target/release-with-debug/deps/libtss_esapi_sys-b8d41d1df3fb3265.rlib
          >>> defined at tcti-swtpm.c:650 (/builds/.../target/release-with-debug/build/tss-esapi-sys-6480e311b983e39c/out/tpm2-tss/src/tss2-tcti/tcti-swtpm.c:650)
          >>>            tcti-swtpm.o:(.text.Tss2_Tcti_Info+0x0) in archive /builds/.../target/release-with-debug/deps/libtss_esapi_sys-b8d41d1df3fb3265.rlib

Fortunately, this was eventually fixed upstream in v4.2.0. After some discussion on the Slack, I'm submitting this PR to bump the minimum version of the underlying library to 4.2.0, so that the bundled feature will (as of v8.0.0 of the tss-esapi crate) statically link correctly.

Missing bindings

I did not find any scripts that touch tss-esapi-sys/src/bindings/x86_64-unknown-darwin.rs. I used the regenerate-bindings.sh script (with some minor modifications to pull in and build libjson-c-dev since I otherwise had a hard time getting it to show up in my sysroot correctly). I can submit those changes separately, on a different PR.

But the fact remains that the default bindings for Apple/Darwin targets haven't been updated. I'd be happy to try and extend the regenerate-bindings.sh script in a similar way to provide those, but I'm not sure if that needs any special kind of care. It was hard to tell if it was missing from the script because it never came up or if cross-compiling via Linux was just unreasonable.

[ionut-arm]

But the fact remains that the default bindings for Apple/Darwin targets haven't been updated. I'd be happy to try and extend the regenerate-bindings.sh script in a similar way to provide those, but I'm not sure if that needs any special kind of care.

If you have the time feel free to have a go at it. I have a vague memory that there were some dependencies that would not allow regeneration for that target, but I might be wrong.

[ThatGeoGuy]

But the fact remains that the default bindings for Apple/Darwin targets haven't been updated. I'd be happy to try and extend the regenerate-bindings.sh script in a similar way to provide those, but I'm not sure if that needs any special kind of care.

If you have the time feel free to have a go at it. I have a vague memory that there were some dependencies that would not allow regeneration for that target, but I might be wrong.

I've actually written about this in the past on my $DAYJOB's company blog:

https://www.tangramvision.com/blog/cross-compiling-your-project-in-rust

Cross-compiling for Apple is an extremely frustrating endeavour, especially if you have any dependencies that need specific Apple toolchains or configurations (although here, that might be mostly managed because openssl/libjson-c/tpm2-tss aren't C++). I'll give it a crack if I have some spare time but otherwise I will probably want to leave that for a separate MR if the state of the current bindings is not blocking (you can always run with the generate-bindings feature locally, so these aren't show-stoppers for using the crate).