[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@…):

 Prompted by jeremyhu's analysis at comment:45, I noticed that the
 **second** pthread_atfork() call is inside libgegl, which is an image
 handling library -- at that I had an older version of that available.  So
 I tried using the older version:

 {{{
 ewen at ashram:~$ port installed | grep gegl
   gegl @0.2.0_12+python27+x11
   gegl @0.2.0_13+python27+x11 (active)
 ewen at ashram:~$ sudo port activate gegl @0.2.0_12+python27+x11
 --->  Computing dependencies for gegl
 --->  Deactivating gegl @0.2.0_13+python27+x11
 --->  Cleaning gegl
 --->  Activating gegl @0.2.0_12+python27+x11
 --->  Cleaning gegl
 ewen at ashram:~$
 }}}

 and after doing that, it's then possible to run GIMP with many fewer
 errors -- and it can actually load non XCF images (eg, it loaded a JPEG
 image for me) so it looks like the plugins work).

 {{{
 ewen at ashram:~$ /opt/local/bin/gimp-2.8
 GEGL-/opt/local/include/glib-2.0/glib/gmessages.h-Message: Module
 '/opt/local/lib/gegl-0.2/ff-load.so' load error:
 dlopen(/opt/local/lib/gegl-0.2/ff-load.so, 10): Library not loaded:
 /opt/local/lib/libavformat.55.dylib
   Referenced from: /opt/local/lib/gegl-0.2/ff-load.so
   Reason: image not found
 While parsing XMP metadata:
 Error: No XMP packet found
 ewen at ashram:~$
 }}}

 So it appears we have at least reached a workaround:

 {{{
 sudo port activate gegl @0.2.0_12+python27+x11
 }}}

 assuming you still have the older version around, and that:
 0. something changed between gegl 0.2.0_12 and 0.2.0_13 which matters
 0. something changed in gegl's build environment recently which matters
 0. not being able to load libavformat matters somehow (I suspect it's not
 loading because it refers to a different libavformat filename)

 A **very** quick play with lldb breaking on dlclose() suggested that
 dlclose() was being called in that gegl path, so the trigger in the
 _atfork() might be something else.  But I don't have much time to play
 with it today, so haven't investigated in any detail.

 Thanks jeremyhu for pointing us in the right direction.

 Ewen

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