Odd non-fatal GIMP Behavior

Tue Nov 18 15:11:35 PST 2014

Um..huh?

I think you have completely confused my intention for this post.

I really do understand the difference between native and non-native 
applications when it comes to Apple, Linux, Unix, Windows, etc.

I compile my GIMP against Quartz, so actually my GIMP is quite native to 
Apple.

-----

When I right-click on a JPEG or PNG or GIF image file, a context menu 
opens up (see the attached screenshot), and there is an "Open With" 
sub-menu that lists compatible applications to open said image file 
with. Because I have my GIMP.app in /Applications, GIMP is one of the 
options.

When I complete the event by choosing GIMP, the dock icon for GIMP shows 
up, bounces once, and then closes. An application crash pop up shows 
with the typical "Ignore" or "Report to Apple" button. Clicking the 
Report button displays the crash log data, from which I pasted the 
actual error in my first post.

However, if I double-click GIMP.app in Finder from the /Applications 
folder, GIMP opens right up like normal. I then am able to open any 
image file I choose, edit, save, export, and close GIMP --or-- I can 
create a new image, save, export, and close GIMP.

As I posted in response to Ryan's request - libiconv is the correct 
version linked to libgobject. So the conclusion I came up with is that 
the ScriptExecCocoa NIB wrapper might be linking to libiconv from Xcode.

SEE:

$  otool -L 
./Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.2.dylib
./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)

Jeff

On 11/18/14 4:22 PM, Michael Crawford wrote:
> 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
> mdcrawford at gmail.com
> 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 <gvibe06 at gmail.com> 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 at minimac ~ $  lipo -info /opt/local/lib/libiconv.2.dylib
>>>> Non-fat file: /opt/local/lib/libiconv.2.dylib is architecture: x86_64
>>>>
>>>> jsingleton at 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 at 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 at minimac ~ $  echo $DYLD_LIBRARY_PATH
>>>>
>>>> jsingleton at 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
>> macports-users at lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-users
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-11-18 at 4.57.36 PM.png
Type: image/png
Size: 147532 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20141118/9b003642/attachment.png>