Crates.io | intel-seapi-sys |
lib.rs | intel-seapi-sys |
version | 0.2.0 |
source | src |
created_at | 2018-10-26 13:34:50.725044 |
updated_at | 2018-10-26 16:47:17.670942 |
description | FFI wrapper for Intel Single Event API (SEAPI) and ittnotify, as used by Intel VTune |
homepage | https://github.com/lemonrock/intel-seapi |
repository | https://github.com/lemonrock/intel-seapi.git |
max_upload_size | |
id | 92759 |
size | 3,770,078 |
intel-seapi is a FFI wrapper for the Intel Single Event API (SEAPI, also known as IntelSEAPI) and ittnotify
, as used by Intel VTune. ITT stands for 'Instrumentation and Tracing Technology'. This particular wrapper uses a fork of IntelSEAPI because the upstream code base doesn't support cross-compilation or the MUSL C library.
It provides a static link and generates Rust FFI bindings to the libittnotify.a/.obj
library, and also compiles , but does not link or generate Rust bindings for, thelibIntelSEAPI.dylib/.so/.dll
dynamic library (this is because it is only ever built dynamically and because it is designed to be used from C++).
Downstream crates can use the generated build variables cargo:include
, cargo:libdir
and cargo:root
.
Does not currently work on Windows, as a completely different set of APIs (ending in A
and W
) are built for Windows by libittnotify
.
The dynamic library IntelSEAPI
is built but not linked and no bindings are generated for it.
Bindgen does not generate correct bindings for most of libittnotify
because the C headers' function declarations do not reflect the actual managled names created. Consequently only a small subset of bindings is provided; additional bindings generated but not yet corrected are in BindingsAsGeneratedByBingen.rs
.
This is brittle, and may fail, mostly because the underlying software uses a mixture of CMake, a C++ toolchain with Rust bindings and wrappers, and IntelSEAPI is not cross-compile friendly. We use a forked version to fix some cross-compilation mistakes in their CMakeLists.txt
files, generation of fat Mac OS X object archives with architectures independent of target or host, etc.
For example, when compiling for MUSL targets, Rust's cc
crate assumes the C compiler is musl-gcc
and the C++ compiler if musl-g++
. Since the cc
crate is managed by the cmake
crate, this is something we can't easy change. This crate attempts to set the environment variable CROSS_COMPILE
if not set already when cross-compiling using a MUSL target.
On Mac OS X, with filo-sottie's foked musl homebrew keg installed (lemonrock/musl-cross/musl-cross
), cargo build --target x86_64-unknown-linux-musl
.
The license for this project is MIT.