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 <ryandes...@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@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 macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users