# Tips for building native libraries for Racket? **URL:** \ **Category:** Questions & Answers\ **Tags:** package, native-libraries\ **Created:** [February 17, 2022, 4:51pm UTC](https://racket.discourse.group/t/tips-for-building-native-libraries-for-racket/706 "2022-02-17T16:51:35Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![simonls](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/simonls/32/170_2.png) [@simonls](https://racket.discourse.group/u/simonls)\ **Post date:** [February 17, 2022, 4:51pm UTC](https://racket.discourse.group/t/tips-for-building-native-libraries-for-racket/706/1 "2022-02-17T16:51:35Z")
In this thread I have described how I solved my problem (ffi bindings are difficult to create) by creating a wrapper library around freetype (simpler to create ffi bindings): > [@FFI define-cstruct recursive dependencies on types](https://racket.discourse.group/t/ffi-define-cstruct-recursive-dependencies-on-types/353/2#native-racket-libraries-4): > > ffi bindings / experience report / what I did first attempt: manual bindings for freetype In my particular case I wanted to use freetype from racket via ffi, but after a while I gave up on trying to create bindings for it directly. The freetype library has deeply nested structs and it is very annoying having to replicate all the type declarations, then eventually you get some type wrong somewhere and the struct alignments don't work anymore and you get a segfault trying to use your faulty bindin… But to be silly and quote myself: > [@FFI define-cstruct recursive dependencies on types](https://racket.discourse.group/t/ffi-define-cstruct-recursive-dependencies-on-types/353/2): > > Except now I have a new problem, because now I have to build that wrapper on every platform where I want to use it. I don't think that this is necessarily difficult, it is more another annoyance. > > For example, when I want to make it easy for people to use that wrapper too, then it is nicer if I provide it for them pre-built and packaged as a racket package. So far I don't have a setup / images / (virtual-)machines to do that. So this topic is mostly me asking for tips: **What can I do to (relatively) easy, create builds for my library and package that as a racket package?** I already have gotten the impression from a few racketeers that it isn't necessarily fun to build the various platform dependent packages. Any insights into what is difficult or what tools could be used would be appreciated. ---
**Author:** ![simonls](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/simonls/32/170_2.png) [@simonls](https://racket.discourse.group/u/simonls)\ **Post date:** [February 17, 2022, 5:01pm UTC](https://racket.discourse.group/t/tips-for-building-native-libraries-for-racket/706/2 "2022-02-17T17:01:12Z")
I already looked a little bit into @bogdan's libsqlite3 package. It seems it uses github actions and for `aarch64` it uses self-hosted runners, is that because there aren't github provided runners for that architecture? I guess for a start I could try to just use what is available out of the box and if there is interest for more architectures then they can be extended in some way or another. But in general I am interest to hear about different ways this problem is being solved, by different people that maintain platform specific builds. ---
**Author:** ![dannypsnl](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/dannypsnl/32/917_2.png) [@dannypsnl](https://racket.discourse.group/u/dannypsnl)\ **Post date:** [February 17, 2022, 5:06pm UTC](https://racket.discourse.group/t/tips-for-building-native-libraries-for-racket/706/3 "2022-02-17T17:06:12Z")
Yes. GitHub didn't provide arm64 for now. ---
**Author:** ![jjsimpso](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jjsimpso/32/602_2.png) [@jjsimpso](https://racket.discourse.group/u/jjsimpso)\ **Post date:** [February 18, 2022, 2:23am UTC](https://racket.discourse.group/t/tips-for-building-native-libraries-for-racket/706/4 "2022-02-18T02:23:25Z")
I'm interested in this question as well, as I am considering making a Racket package to access CPU performance counters on Linux. Unfortunately, glibc doesn't provide an API for this, so my plan is to create my own library in C to handle the low-level details. I'd like to include this lib as part of my final Racket package. Is that accepted practice? To include a pre-built shared object as part of a Racket package? ---
**Author:** ![SamPhillips](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/samphillips/32/15_2.png) [@SamPhillips](https://racket.discourse.group/u/SamPhillips)\ **Post date:** [February 18, 2022, 2:42am UTC](https://racket.discourse.group/t/tips-for-building-native-libraries-for-racket/706/5 "2022-02-18T02:42:45Z")
If you are using [`perf_event_open`](https://man7.org/linux/man-pages/man2/perf_event_open.2.html), you should be able to use the Racket FFI and access it with `syscall`, `ioctl`, etc. ---
**Author:** ![jjsimpso](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jjsimpso/32/602_2.png) [@jjsimpso](https://racket.discourse.group/u/jjsimpso)\ **Post date:** [February 18, 2022, 3:40am UTC](https://racket.discourse.group/t/tips-for-building-native-libraries-for-racket/706/6 "2022-02-18T03:40:40Z")
Yes, I am and that is an option as well, but I wasn't sure how portable it would be. I figured I could account for portability on the C side and provide a consistent interface to Racket code. I haven't written the code yet, so maybe portability isn't as much of a problem as I thought.