Regarding libevent... Would making sure EVENT__HAVE_KQUEUE is not set be too crude of a workaround (for now at least)? I mean... if the code worked without kqueue before... :-)

Or we could try using #ifdef EVFILT_SIGNAL blocks (as done for Python's socketmodule.c). But then I'm not sure if we should also "nuke" kq_sig_add()/kq_sig_del() (at least from the struct eventop kqsigops).

Yes, forcing libevent to not enable kqueue support until this is improved on Haiku side should be fine. I think disabling just parts of the kqueue implementation would be a bad idea, it would then only half-work

• gtkwebkit is currently built against ICU 66 instead of a newer 74 or even 75

It even uses LLVM12

webkit-gtk needs cmd:xgettext atleast in BUILD_PREREQUIRES, but build errors atm (link will stay up for a week): https://bpa.st/LGMA

I think disabling just parts of the kqueue implementation would be a bad idea, it would then only half-work

It turns out the signal handling is basically separate from the event handling and can be safely disabled (and libevent can then use its standard signal handling routines.) I sent @OscarL a patch to test, seems to work here after a fix to kqueue in Haiku, and should be much more performant (and not prone to strange races.)

Thanks, I was able to rebuild it, should be fine now!

@pulkomandy so the fluidsynth PR can be closed?

I'm not sure what the status is with flac13 on x86, didn't check that yet (and I will not be in front of my 32bit machine for a few days).

Build wise flac13 is fine, I only started to look into it because it was mentioned here, if there are no problems anymore maybe it's pointless medling with the existing packages atm? (given that there are no newer versions involved)

I would like to retire older versions of packages and keep only the latest one as much as possible. In the case of flac, the latest one is flac 1.4, and I was trying to move all recipes to that, so flac13 can be removed.

I find these old packages annoying (why have two versions of a thing when you can have just one), and also potentially a source of problems if the two versions of a library end up being loaded in the same application (for example we know this is a problem with openssl 3 vs openssl 1.1, but it can be also with other libraries).

Anyway, no problem about it, I will keep that in my TODO list as a background task to try to keep at least my computers with only one version of each library installed, and rebuild things as needed to achieve that goal.

OK fair enough, trying to "uninstall" flac13 here seems to bring down multiple packages, will do some checks on it here also, as for fluidsynth2 it builds fine with current flack 1.4, just not for gcc2 (either flac version), but maybe that can be dropped?

EDIT: building 64bit fluidsynth2 with flac 1.4 narrows down deps on flac13, only opus_tools and vorbis_tools show up here. :)

EDIT2: on 32bit fluidsynth2 gcc2 still relies on flac13, sdl2_mixer is tied to that so uninstalling flac13 (gcc2) leads to uninstall fluidsynth2 and sdl_mixer.