Odd non-fatal GIMP Behavior

[Ryan Schmidt]

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.