Closed #241.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/241#event-3381359899
Got this working using `lazy_static` to inject a synchronizable object into my
ocall.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/241#issuecomment-635147568
Is it possible to use ocall with async channels (like in this pseudo code)?
```rust
fn subscribe() {
let (mut tx, mut rx) = mpsc::unbounded::();
// I know that I can't declare an ocall inside a fn
// I want to illustrate of accessing the Receiver in the ocall
fn ocall_pick_number(out_number
Thank you so much guys! These were all the right clues. I did recently start
using `rand::thread_rng` in the untrusted module. I suspect that this is what
caused the error rather than the SDK upgrade. Setting
`0` worked although I'm reading more about it to
understand its ramification.
--
You
Closed #240.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/240#event-3374711324
I recently upgraded to sdk 1.1.2, and I'm getting this error with a TLS client
similar to the example provided.
```
thread '' panicked at 'Can not access a Thread Local Storage value:
AccessError { msg: "If TLS data needs to be destructed, TCS policy must be
Bound." }',
/root/.cargo/git/checkou
I was able port this crate, at least according to my needs.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/238#issuecomment-633793786
Closed #238.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/238#event-3371781087
@mssun You were right. I confused error-chain backtrace module with the std. I
got past this issue but now getting the error below. Like @dingelish suggested,
I'm just trying to port the crate.
```
error[E0308]: mismatched types
-->
/root/.cargo/git/checkouts/error-chain-cd67bb92899312ae/f73f
@dingelish Yes, I would appreciate help with the porting.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/238#issuecomment-631166354
I'm trying adapt the `error-chain` crate. It relies on the `backtrace` crate
which I replaced by the backtrace feature of tstd. I don't know what to do with
the hidden `InternalBacktrace` here:
https://github.com/rust-lang-nursery/error-chain/blob/44c9240940e974695386cb7b9ab020df1147dbfe/src/lib
Thanks for looking into this. I still get this error when I start it "manually"
in the shell. But it is running.
```
root@75dbac795724:~/sgx/samplecode/hello-rust/bin#
/opt/intel/sgx-aesm-service/aesm/aesm_service/opt/intel/sgx-aesm-service/aesm/aesm_service:
error while loading shared libraries
Closed #237.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/237#event-3349842033
I did that. I also included it in my Dockerfile.
```
FROM baiduxlab/sgx-rust:1804-1.0.9
RUN echo 'LD_LIBRARY_PATH=/opt/intel/sgx-aesm-service/aesm
/opt/intel/sgx-aesm-service/aesm/aesm_service &' >> /root/.bashrc
```
Any other guesses?
--
You are receiving this because you are subscribed to thi
I just upgraded from 1.0.9 to `sgx-rust:1804-1.1.2` and I can no longer start
the aesm_service in the docker container.
```
root@7216fc5a8208:~# /opt/intel/sgx-aesm-service/aesm/aesm_service
/opt/intel/sgx-aesm-service/aesm/aesm_service: error while loading shared
libraries: libCppMicroServices.
15 matches
Mail list logo
