FIXED: I replaced g_spawn_async with posix_spawn and the plugins worked now!
41 Likes
The didn’t drop it. It was not made by the Abiword team, someone ported it to BeOS on their own. The code was quite a mess and had a lot of problems. Eventually the person who was doing it stopped maintaining it. And Abiword didn’t want to upstream that code without a maintainer to take care of it, which makes sense.
The code is still available at GitHub - HaikuArchives/AbiWord: The old AbiWord for BeOS. . I made some fixes on it back in 2014, but it isn’t the latest version of Abiword and it is also really unstable due to problems with threading (this port completely ignore the fact that there are separate threads for the window and application, and accesses things from both without any locking. I suspect it ran kind of OK on single CPU machines back then?)
5 Likes
I don’t know if the port in HaikuArchives is the same code,but AbiWord did have upstream support for BeOS years ago.
Here’s the commit which removes it: https://github.com/AbiWord/abiword/commit/e153cb594fdc9d781c8c687d29a47c0a60ada980
Sadly,it was removed earlier than I thought and probably difficult to reuse on top of a more modern version 
1 Like
Abiword never worked well for BeOS… I remember how often it crashed!
3 Likes
Then Audacity can be ported more easily now? i suppose, Audacity is like the gimp for audio.
1 Like
g_spawn_async is supposed to use posix_spawn if it is available, already. Does it not for some reason on Haiku? We should fix that if so, probably other things make use of it.
8 Likes
Very strange, but indeed at the moment glib2 uses posix_spawn in g_spawn_async. A direct call from GIMP posix_spawn works fine, but g_spawn_async throws an exception. Apparently we need to build glib2 with debugging information and find out the reason.
2 Likes
The problem has been found, and it is, after all, inside haiku.
The implementation of g_spawn_async in glib2 calls posix_spawn with parameters file_actions and spawnattr set. If these parameters are not NULL, haiku uses fork(), and if they are NULL, it uses image loading - spawn.cpp « posix « libroot « system « src - haiku - Haiku's main repository.
Loading plugins in GIMP only works correctly if load image is used.
3 Likes
That doesn’t seem to make much sense. Why does fork() not work here?
I don’t know. Calling fork or vfork from gimp causes an instant exception.
UPD: not an exception, but a Sigmentation Violation signal
2 Likes
The GIMP recipe (and missing dependencies) is published.
Known problems at the moment:
- Hangs when trying to open Preferences dialog (fatal error: Segmentation vialation).
- Inverting the colors on the canvas. Apparently an error somewhere in xlibe - wrong RGB <-> BGR order.
16 Likes
It can make sense if things like pthread_atfork(3) - Linux manual page are involved. Or also if file descriptors have the close-on-exec flag set (this will happen at exec and not fork time), but don’t expect posix_spawn to do that, and so they additionally used https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn_file_actions_addclose.html to cover that case?
Seems like there are amny things that can possibly go wrong
4 Likes
It would be good to get HaikuPorts tickets for this and the fork() crashes.
Possibly it wants to use LSB/MSB flags in XImage, I didn’t implement that. I can take a look.
11 Likes
'Twas indeed a bug in Xlibe’s XImage processing. Now fixed, and the new version is in HaikuPorts:
32 Likes
do the 3d modelling features work ?
What did do to get that Dark theme?, i’ve been trying with gsettings with no luck.
Very niiiiiiiiice…
I’ve just made an update to Xlibe which should allow for the system fonts to be used in GIMP (and all other GTK applications). That should improve integration somewhat 
22 Likes
Is gimp only 64bit? i do not see it in 32 it haikudepot
Disabled in the recipe:
1 Like