What's the "modern" way to talk to C libraries?

When I started with Perl in the previous century, one of its highlights was its use as a "glue" language, and its ability to make simple things easy. GD is the first I recall, later I had fun with the inevitable DBI, did some work with XML::LibXML and a lot of others I am to lazy to recall right now. Then came THE WEB and Perl developers (including me) seem to have changed their focus (and also: Many new developers solved web problems using Perl). In the last two years, when I played with 3D graphics and sound, I was a bit disappointed about the amount of stale / abandoned CPAN modules in that area. I was able to use Audio::PortAudio (most recent release in January 2007) to record sound from my microphone, but only after suppressing a bunch of warnings, and I was surprised that it worked at all.

Looking for a contemporary way to do sound on Linux, I stumbled over PipeWire. It comes with a set of CLI commands, decent documentation, and a tutorial in C. I want to do two things: 1) record and play sound without shelling out to an external program, and 2) detect whether a microphone is actually plugged in so that I can enable/disable the "record" button in my GUI accordingly. But like many "modern" C libraries, PipeWire utterly sucks at making simple things easy. So I thought: How hard can it be to use that library from Perl?

I am not at all an expert in this area. I have not used C since about 20 years and never tried XS programming. I have heard good things about FFI::Platypus, so I thought I would give it a try. It turned out to be a roller coaster of success and failures.

FFI::Platypus does not really support several constructs used by the library (dynamically sized arrays of structs, callbacks returning pointers to a struct, ...). I also need to manually copy-write every single struct in terms of FFI::Platypus (or FFI::C) which stops to be fun after the first two dozen structs. The (very good, BTW) docs point to Convert::Binary::C for these things, so I added that to the mix. I found that it didn't handle current C compilers (the maintainer has fixed this on GitHub, no CPAN release yet) and can not handle many of PipeWire's header files because they make heavy use of GCC extensions. I also learned that Convert::Binary::C is in "bugfix-only" state. I have segfaults (same thing as these) which suggest that the Perl we get from Linux distributions can not handle the library at all, so I build my own Perl for this experiment.

Of course, there's also the XS route, and Dave Mitchell has announced his plan to Rewrite the XS pod files. I am somewhat impatient to see this, but as far as I know the tedious task of re-writing every struct (called "typemaps" in XS) isn't much easier than doing it with FFI::Platypus.

My current route is to use Convert::Binary::C to auto-generate Perl classes equivalent to the C structs. This is actually fun, but also time consuming and I am afraid that I get lost in abstractions over abstractions and never get to actually use the Perl library.

So, while I am still making progress, I wonder: Are there other developers around who work with C libraries these days? How do they do it? Or is this an art soon to be obsolete?

Comment on What's the "modern" way to talk to C libraries?

Replies are listed 'Best First'.
Re: What's the "modern" way to talk to C libraries? by Corion (Patriarch) on Nov 24, 2025 at 07:58 UTC
Personally, I like to start out with Inline::C, and then pull out the XS file that Inline generates. This gives me a quick start without needing to worry too much, but Inline::C still has me writing C and the interface doesn't really create perlish APIs. I usually wrap the C part then with more Perl to create a perlish API over the C API. The ugly part IMO is handling `struct`s that you get from C. I haven't found a good way to automatically generate a converter from a C-struct to a Perl hash (and be it a tied hash into the C data structure). Convert::Binary::C did this, but if it is failure-prone nowadays, that's no fun. I have enough to debug with the segfaults in my code, I don't want segfaults introduced by other code as well...	[reply] [d/l]
Re^2: What's the "modern" way to talk to C libraries? by haj (Vicar) on Nov 24, 2025 at 11:16 UTC
This was my initial step, too: Run the PipeWire tutorial sources in Inline::C. But then, I did not want write my own stuff in C. And yes, handling `struct`s is the interesting part. PipeWire comes with ~200 header files and way too many structs to do that manually. Convert::Binary::C (CBC) does exactly this: Convert a C `struct` into a Perl hash (reference) at runtime. It also provides all the meta data I need: If a `struct` contains a `struct some thing`, then the conversion will give me a Perl scalar containing the pointer as an integer value, and CBC also tells me that this scalar is a pointer to `struct some`, which then can be recursively unraveled. That's pretty awesome. CBC is not* error prone at runtime: It does not cause segfaults. It says that it can not handle the syntax in some header files which happens during the development cycle. Working around this is a bit annoying, but not impossible. The main downside with my current project is the lack of portability. PipeWire is Linux-only, no chance on Windows. Its headers can only be compiled with GCC, not a big restriction when we are on Linux anyway. It also does not work with system Perl (or any other Perl built with `useithreads=define`). So while I can shrug it away, that code is unlikely to be useful on CPAN and will never make it into a Linux distribution.	[reply] [d/l] [select]
Re^3: What's the "modern" way to talk to C libraries? by cavac (Prior) on Nov 24, 2025 at 15:08 UTC
Usually i like to use Inline::C and/or handcode stuff, but... The last two weeks i had to make Bindings to some closed source library (only headers + .so available) for work. My enthusiasm for supporting binary blobs is limited at best. So i asked AI (claude) to do all the low level XS stuff for me, starting with h2xs to make the project, then generate all the missing stuff and generate a high level Perl module on top of that. It's not perfect, but it works (for the most part). It's called Lib::Pepper PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP Also check out my sisters artwork and my weekly webcomics	[reply]
Re: What's the "modern" way to talk to C libraries? by syphilis (Archbishop) on Nov 24, 2025 at 10:28 UTC
Are there other developers around who work with C libraries these days? I still work with C libraries, and I still use Inline::C and XS for the task. Or is this an art soon to be obsolete? I bloody hope not. If perl were to obsolete XS (as happened with Perl6) then that would be a perl to which I do not update. Cheers, Rob	[reply]
Re^2: What's the "modern" way to talk to C libraries? by haj (Vicar) on Nov 24, 2025 at 13:17 UTC
If perl were to obsolete XS (as happened with Perl6) then that would be a perl to which I do not update. I might have worded that wrong: I did not want to suggest that this could happen (see my link to Dave Mitchell's mail)!	[reply]