Re: [apache/incubator-teaclave] questions about custom Executor (#430)

My plan now is to write a golang dynamic library, which provides golang computing tasks. Then connect the dynamic library to execution_service (executor), I found that the connection action is in cmake/scripts/sgx_ link_ sign.sh So I add dynamic library connection to this script ![image](https

Re: [apache/incubator-teaclave-sgx-sdk] New 1.1.3 breaks older mesalock packages? (#282)

you're right. hashbrown 0.9.0 does not compile on 2020-04-07 and sgx_tstd v1.1.3 does depends on 0.9.0. and v1.1.3 does requires nightly-2020-10-25 or later not only because the change of `Extend` trait, also the changes in `core::alloc` traits/error types. i just updated the readme. could you

Re: [apache/incubator-teaclave-sgx-sdk] New 1.1.3 breaks older mesalock packages? (#282)

That's the thing - I'm using 2020-04-07, trying to compile with the v1.1.2 sdk, running the exact same compile script inside a docker container that was working a couple of days ago. I suspect hashbrown 0.9.0 doesn't compile with 2020-04-07, and it was added as a dependency when you bumped a few

Re: [apache/incubator-teaclave-sgx-sdk] New 1.1.3 breaks older mesalock packages? (#282)

hey @Cashmaney , thanks for the report! the reason is that `extend_one` was changed to be under `extend_one` feature in https://github.com/rust-lang/rust/issues/72631 , and i guess you're using new compiler (something between 2020-04-07 and 2020-10-25) on v1.1.2 sdk, which requires the old libc

[apache/incubator-teaclave-sgx-sdk] New 1.1.3 breaks older mesalock packages? (#282)

Hey guys, trying to compile the same code that depended on 1.1.2 now fails ``` version. This may also occur with an optional dependency that is not enabled. Compiling sgx_signal v1.1.2 (https://github.com/apache/teaclave-sgx-sdk.git?tag=v1.1.2#8f065be7) Finished release [optimized] target(