I've just got hold of a card and looking into this.
Do you mean a dongle? I got one of the $20 ones, which works pretty well in Windows with SDR# and RTL1090, so I bought a second one.
By specification, pthread_mutex_unlock() has undefined behaviour when unlocking a mutex which is already unlocked.
I wondered about that. If it wasn't either locking something already locked our unlocking something already unlocked. I stuck a bunch of extra printfs in the code and was trying to keep track of what it was doing. It works under Linux, but that's like saying a web page works fine in IE. Too sloppy to do otherwise.
Currently OpenBSD's "undefined behaviour" in this case is to immediately abort(), which has helped debug problems with some threaded programs.
You can change this behaviour by hacking librthread/rthread_sync.c:218 and building/installing new librthread, this gets rid of the crash but does not make things work properly; like rtl_test, rtl_fm doesn't stop when you ^C. I don't get any output from rtl_fm instead I get high system cpu usage. I suspect this is some issue (quite possibly kernel driver) with bulk transfers.
I wonder if the not stopping is because the low level acquisition, possibly a different thread, isn't getting stopped.
Info: This tool will continuously read from the device, and report if samples get lost. If you observe no further output, everything is fine.
I seem to always have samples getting lost, no matter what I do I think it's also supposed to give you a ppm adjustment figure, but I worked out mine from tuning in a few stations and seeing how far off frequency they were (with SDR#). One dongle is off 102 ppm, the other 62 ppm.
I forgot to mention it, but rtl_sdr (the simplest one) also doesn't work. I was looking at trying to adapt them to use the Gnu pth threads.
Notably the two programs which do seem to work correctly are rtl_eeprom and rtl_tcp (at least I get some data from rtl_tcp but don't have anything setup to use it yet) - notably these two do *not* use rtlsdr_read_sync i.e. bulk transfers.
There's a scanning client for rtl_tcp somebody wrote, but they did it in Python. It has one dependency that seems badly packaged. I don't have it working yet. I was thinking of writing a command line scanner in C that has hopefully no dependencies.
Are you sure your rtl_tcp is actually working? Mine stops after a while. You could test it by running SDR# on a Windows machine and having the source of that be the rtl_tcp on an OpenBSD box, just enter the IP address and port. I think it's a lot of network load for even 100baseTX though. There are also Gnuradio sources that can work from rtl_tcp.
OpenBSD isn't the only system which has the realtime functions in libc; this might be more generally applicable but note I have not tested it on a system which *does* have librt.
I could in principle do that. I can boot this box into an old Debian and try that.
Alan