Tips for building native libraries for Racket?

[simonls]

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

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 bind…

But to be silly and quote myself:

@simonls

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.

[simonls]

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.

[dannypsnl]

Yes. GitHub didn't provide arm64 for now.

[jjsimpso]

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?

[SamPhillips]

If you are using perf_event_open, you should be able to use the Racket FFI and access it with syscall, ioctl, etc.

[jjsimpso]

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.