If you select a document in the Finder, then ask that it be opened in an application - or just double-click it - the Finder will launch the application, then shortly after it will send the application an "Open Document" Apple Event.
However, GIMP is a *NIX/X11 application, so it does not natively support Apple Events, which were introduced in Mac OS System 7. So somewhere in there, there must be a "wrapper" that receives the Apple Event as if it were a regular sort of native OS X program - Cocoa or Carbon - then it translates the request into something that the native Linux GIMP builds would do. Quite likely the problem is not actually in libiconv, but something else is screwed up earlier in time, but only causes trouble when libiconv is called. My understanding is that the original Apple Event Manager as documented in Inside Macintosh, Volume 6 works completely unmodified to this very day - it's binary compatible, you don't even need to recompile old source - but you're going to have a hard time getting anyone at Apple to admit to that fact. The closest any of today's "Official" Apple developer doc comes to mentioning Apple Events is that Cocoa provides some support in Cocoa/Objective-C code that's required to support AppleScript. But what AppleScript actually does is send Apple Events to event-driven applications, as well as receive them from those apps. More or less an Apple Event is a network packet that's dropped into your GUI event quite along with mouse clicks and keypresses. I wrote a paper on the Word Services Apple Event Suite for the MacHack '94 conference proceedings that explains Apple Events in general pretty well, there is also a Develop magazine article called "Apple Event Objects and You" that I have a PDF of. However my old site fell over, I haven't put this stuff up on my new site yet. I'll do so in the next day or so. Also I have some straightforward sample code in C. Hope That Beats The Subject Completely To Death, Mike Michael David Crawford [email protected] http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. On Tue, Nov 18, 2014 at 10:58 AM, Jeff Singleton <[email protected]> wrote: > On 11/18/14 12:34 PM, Ryan Schmidt wrote: >> >> >>> On Nov 18, 2014, at 12:30 PM, Jeff Singleton wrote: >>> >>> On 11/18/14 12:20 PM, Ryan Schmidt wrote: >>>> >>>> otool -L/Users/USER/*/GIMP.app/Conte >>> >>> >>> jsingleton@minimac ~ $ lipo -info /opt/local/lib/libiconv.2.dylib >>> Non-fat file: /opt/local/lib/libiconv.2.dylib is architecture: x86_64 >>> >>> jsingleton@minimac ~ $ lipo -info >>> /Applications/GIMP.app/Contents/Resources/lib/libgobject-2.0.0.dylib >>> Non-fat file: >>> /Applications/GIMP.app/Contents/Resources/lib/libgobject-2.0.0.dylib is >>> architecture: x86_64 >> >> >> Ok, so the architectures match. >> >> >>> jsingleton@minimac ~ $ otool -L >>> /Applications/GIMP.app/Contents/Resources/lib/libgobject-2.0.0.dylib >>> /Applications/GIMP.app/Contents/Resources/lib/libgobject-2.0.0.dylib: >>> /opt/local/lib/libgobject-2.0.0.dylib (compatibility version >>> 4201.0.0, current version 4201.1.0) >>> /opt/local/lib/libglib-2.0.0.dylib (compatibility version >>> 4201.0.0, current version 4201.1.0) >>> /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, >>> current version 8.1.0) >>> /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current >>> version 1.0.0) >>> /opt/local/lib/libffi.6.dylib (compatibility version 7.0.0, >>> current version 7.2.0) >>> /opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, >>> current version 10.2.0) >>> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon >>> (compatibility version 2.0.0, current version 157.0.0) >>> >>> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation >>> (compatibility version 300.0.0, current version 1151.16.0) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >>> version 1213.0.0) >> >> >> This looks reasonable. It's linked with the correct libiconv library. >> >> You're sure we're looking at the correct GIMP.app here? The error message >> implied the GIMP.app was in /Users but this one is in /Applications. >> >> >>> jsingleton@minimac ~ $ echo $DYLD_LIBRARY_PATH >>> >>> jsingleton@minimac ~ $ >> >> >> Ok... so you don't have it set in your terminal. But does GIMPskel set it? >> >> > > I launched GIMP.app from /Applications ... and I don't really get why the > crash dump would substitute my actual Users folder with /Users/USER/*/? Is > that a built-in alias for my actual Users folder? > > Because GIMP.app is definitely not in my Users folder. Has my Yosemite lost > its marbles? > > _______________________________________________ > macports-users mailing list > [email protected] > https://lists.macosforge.org/mailman/listinfo/macports-users _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
