-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add cross-compilation example to nightly #206
Conversation
NOTE: I've updated the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Very nice work! The README.md and script will be very useful for users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My knowledge of cross compilation is a bit limited with that in mind I have really nothing against how it looks now. One thing that seemed odd to me was how the cross compilation of the tpm2-tss lib was dependent on OpenSSL. Should it not be the other way around?
Another thing is that the 2.3 versions of tpm2-tss lib have a few naming errors that will be a little bit annoying to deal with (like it better when it was generated from 2.4.X and we didn't tell any one hehehe). Not a big deal everything is U32 in the end any way.
@@ -3306,13 +3282,13 @@ impl Default for TPMS_AUTH_RESPONSE { | |||
} | |||
pub type TPMI_AES_KEY_BITS = TPM2_KEY_BITS; | |||
pub type TPMI_SM4_KEY_BITS = TPM2_KEY_BITS; | |||
pub type TPMI_CAMELLIA_KEY_BITS = TPM2_KEY_BITS; | |||
pub type TPMI_TPM2_CAMELLIA_KEY_BITS = TPM2_KEY_BITS; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know we are supporting version 2.3.3 and unfortunately we then have to deal with these kind of bugs. I wonder if it would be possible to bump the minimum supported tpm2-tss version soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, yeah, we're going to tread carefully on that on the Parsec side - I'll try and think of a way of bumping the minimum supported version in the crate without burning down support for Parsec.
Potentially keeping the 2.3.3 version supported in a separate branch and move on with master
? (it wouldn't involve porting every new feature to it, only stuff that we in Parsec need, and important bugfixes)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that forking the crate is going to be great for anyone.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@puiterwijk - is there some standard way of making something like this work, that you know of? Or are we going to end up in hell either way we try
@Superhepper - what version did you have in mind? >=2.4.0 or straight up 3.0.0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, we could go back to the idea of having a feature for which version of the TSS you're using, and then change implementation details based on that (maybe just have both of them in a side-module).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, straight up 3.0 would not be advisable because I think there still a lot of people running 2.x. But some 2.4 release would be nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(And then, based on the version during install, put in a fake version of the new constant, so that we can just assume the lateest version exists, but maybe it comes from bindgen, maybe from our own version)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've raised #207 - will start looking at it soon
Sorry, forgot to reply to this - it does seem a bit weird that |
This commit adds cross-compilation to armv7 and aarch64 to the nightly build. This involves modifications to the way `pkg-config` is used as described in parallaxsecond#204. Signed-off-by: Ionut Mihalcea <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good for me!
Fix clippy errors
This commit adds cross-compilation to armv7 and aarch64 to the nightly
build. This involves modifications to the way
pkg-config
is usedas described in #204.
Fixes #204