Odd non-fatal GIMP Behavior

[Jeff Singleton]

I don't think that GIMPskel project has been updated in a long time.  I
found that it still requires libcups* for some reason....so I manually copy
those files from /usr/lib into the $TOP/lib folder. Wrong or right,
GIMPskel serves its purpose, at least for me.

That DYLD thing is probably easy enough to fix...I will try removing it and
see what happens.

--


On Wed, Nov 19, 2014 at 9:47 PM, Ryan Schmidt <ryandesign at macports.org>
wrote:

>
> On Nov 18, 2014, at 10:46 PM, Jeff Singleton wrote:
>
> > On 11/18/14 7:17 PM, Ryan Schmidt wrote:
> >> find ~ -name GIMP.app 2>/dev/null
> >
> > The only other GIMP.app is in the GIMPskel folder in my Downloads folder
> where I build the application bundle.
> >
> >       jsingleton at minimac ~ $  find ~ -name GIMP.app 2>/dev/null
> >       /Users/jsingleton/Downloads/GIMPskel/GIMP.app
> >       jsingleton at minimac ~ $
> >
> > The only clear thing here is that what is shown in the error does not
> reflect the truth. When I open Finder, and then click on Applications, and
> then double-click on GIMP.app, how exactly is that my Users folder?
> >
> >       jsingleton at minimac ~ $  ls -1 /Applications/G*
> >       /Applications/GIMP.app:
> >       Contents/
> >
> > Its not symlinked...therefore its not starting from my Users folder.
>
> I understand that. You said that double-clicking the application worked
> fine, so I'm not concern about what happens when you double-click it. You
> said that selecting "Open With" from an image file was not working; that's
> what I'm concerned about. I was concerned that "Open With" was selecting a
> different copy of GIMP.app, one in your Users folder, not in your
> Applications folder, and I'm still not convinced that's not the case. You
> could try removing the copy in your Users folder and seeing if the problem
> persists.
>
>
> > Lastly, that error mentioned version 7.0.0 of libiconv.2.dyld being the
> issue.
>
> The ProblemHotlist entry I referred you to explains the circumstances
> under which that error can occur: architecture mismatch (which we already
> determined is not the case), or DYLD_LIBRARY_PATH is set.
>
>
> > Because I am using what some might consider the ancient method for
> creating an application bundle of GIMP, via the GIMPskel package from
> Sourceforge - this method requires me to build ScriptExecCocoa.
>
> I downloaded GIMPskel from SourceForge, and it does indeed set
> DYLD_LIBRARY_PATH:
>
> $ grep DYLD -r GIMPskel
> GIMPskel/GIMP.app/Contents/Resources/bin/gimp:export
> "DYLD_LIBRARY_PATH=$TOP/lib"
> GIMPskel/GIMP.app/Contents/Resources/bin/gimp-remote:export
> "DYLD_LIBRARY_PATH=$TOP/lib"
>
> So that could well be the problem. It is usually an error to set
> DYLD_LIBRARY_PATH and they should not be doing so.
>
>
> > Digging into Xcode.app under the 10.10 SDK folder, there is in fact a
> libiconv.2.dylib - and running the otool command on that shows this:
> >
> > jsingleton at minimac ~ $  otool -L
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.2.dylib
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.2.dylib:
> >       /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current
> version 7.0.0)
> >       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1213.0.0)
>
> Yes, we are aware that the libiconv provided by OS X and the OS X SDKs is
> compatibility version 7.
>
>
> > So I made some changes to the ScriptExecCocoa.xcodeproj to force it to
> use the libiconv.2.dylib from MacPorts, and bam, no more crash.
>
> Ok, I'm glad you found a solution that works for you.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20141119/ac5bf9c7/attachment.html>