[MacPorts] #45309: gimp2 @2.8.14 on 10.9 - doesn't load plug-ins

[MacPorts]

#45309: gimp2 @2.8.14 on 10.9 - doesn't load plug-ins
---------------------------+----------------------
  Reporter:  and.damore@…  |      Owner:  devans@…
      Type:  defect        |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:
Resolution:                |   Keywords:
      Port:  gimp2         |
---------------------------+----------------------

Comment (by macports@…):

 Replying to [comment:14 zhu527812567@…]:
 > It seems that we'd better report this issue to upstream glib. This issue
 seems
 > similar to ours: https://bugzilla.gnome.org/show_bug.cgi?id=738620 .

 That does seem wise.  Thanks for pointing out that glib ticket, which does
 seem similar to me too.  Since I've already got an account on the Gnome
 bug tracker I've added a "BTW" pointer to this MacPorts ticket there with
 this text:

 > Potentially related, over at the MacPorts (OS X) site there is ticket
 #45309 for Gimp failing to launch DBUS or detect
 > any plugins since new versions of glib/gtk/gimp were incorporated into
 MacPorts about 11 days ago (so around
 > 2014-10-10 ish).  On the DBUS launch there's a "Not enough memory" error
 report.  It's worked fine for years prior to
 > that.
 >
 > As far as I can tell gimp detects plugins by launching something, via
 glib functions, to auto-discover them (and
 > the DBUS case is definitely supposed to be a program launch).  Based on
 the debugging to date it looks like
 > something in the fork() child is failing before it is able to get as far
 as calling exec*() -- but we have not
 > yet determined precisely what.  Memory allocation is one plausible
 theory, especially given the "Not enough
 > memory" report.
 >
 > Ticket URL: https://trac.macports.org/ticket/45309
 >
 > Seems to affect OS X 10.6.8, 10.7, 10.9 and 10.10 (beta) at least.
 >
 > It appears that on OS X the relevant glib functions do work in some
 other gtk applications (eg, eog is mentioned
 > in the ticket), but not in gimp.  My hunch is that single threaded
 applications have different malloc-after-fork
 > rules than multi-threaded applications.

 But I suspect if anyone gets closer to narrowing down the trigger event on
 OS X then it'd also be worth creating our own upstream ticket with more
 specific detail.  And/or if we can narrow it down to a specific upstream
 version change.  Particularly since the tone of that upstream ticket is
 basically "following POSIX is hard" (which it is, to follow strictly) and
 suggesting that they "need" to do things that do not follow POSIX.

 Ewen

-- 
Ticket URL: <https://trac.macports.org/ticket/45309#comment:15>
MacPorts <https://www.macports.org/>
Ports system for OS X