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@minimac ~ $ find ~ -name GIMP.app 2>/dev/null > /Users/jsingleton/Downloads/GIMPskel/GIMP.app > jsingleton@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@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@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. _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
