Welcome to the MacNN Forums.

ksloan2 · Apr 21, 2006, 03:31 PM

I found a very nice image viewer, which unfortunately wasn't a universal binary. However, the source was availible as an xcode project, so I downloaded that.

Sadly, it doesn't build and fails because of "jam" with error code 1. I've googled the problem, and it seems that there can be various reasons for it, and to really figure it out, you need to run some sort of extra debug level using the command line, since "jam" isn't native, apparently.

I have no idea how to do this, so I'm wondering if some friendly soul can take a look at the project and maybe see what needs to be done in order for it to compile as a universal binary:

http://soulcrushingjob.com/archives/000391.php

Thanks in advance to whoever tries this.

Wevah · Apr 22, 2006, 06:12 AM

You probably need to upgrade your target and make sure you're using an installed GCC binary.

ksloan2 · Apr 24, 2006, 05:37 AM

Embarrasing, but I know too little about Xcode to understand what you meant (I looked at the targets and they only seem to describe a normal build process, with no indication of where I can change anything).

I guess I will have to wait until I have time to Google some more, since this is apparently a legacy problem that I'm having.

Thanks for the tip anyway.

Wevah · Apr 24, 2006, 05:35 PM

Ah; sorry. You need to choose "Project -> Update All Targets", and then Get Info on the updated target (I'm guessing there's only one target in the project before the update), go to the "Build" tab, scroll to the bottom, and remove the two lines labelled "CC" and "CPLUSPLUS" on the left side. It should build, though there are a bunch of warnings (I'm assuming because of header files that should have been imported).

ksloan2 · Apr 25, 2006, 12:30 PM

Thanks so much for the help! It compiled now, and with warnings, as you said, but it worked!

And the application is snappy too, really nice and exactly what I wanted.

The only thing is I don't know why it works... and if it's "dangerous" to run the application too much, since there's some worrying text in the warnings:

Code:
MagicDirectory.m:70: warning: method possibly missing a [super dealloc] call
MagicImageCache.m:39: warning: method possibly missing a [super dealloc] call
MagicResponder.m:43: (Messages without a matching method signature will be assumed to return 'id' and accept '...' as arguments.)
MagicResponder.m:43: warning: no '-changeImageFile:' method found
MagicResponder.m:49: warning: no '-changeImageFile:' method found
MagicResponder.m:84: warning: no '-toggleFullScreenInfo:' method found
MagicResponder.m:84: warning: no '-magicController' method found
MagicResponder.m:92: warning: no '-returnFromFullScreen' method found
MagicResponder.m:92: warning: no '-isFullScreen' method found
MagicResponder.m:97: warning: no '-changeImageFile:' method found
MyDocument.m:238: warning: passing argument 2 of 'SetSystemUIMode' makes integer from pointer without a cast
MyDocument.m:246: warning: passing argument 2 of 'SetSystemUIMode' makes integer from pointer without a cast

The missing a "super dealloc" sounds like it leaks memory somewhere. I wonder if this will permantently affect OS X over time unless I reboot?

And how can it work, and change images and go to fullscreen when the compiler is confused wether those methods exist or not?

These are also more warnings now, than what I received the first time I compiled it, oddly enough.

Anyway, since it is now compiling, I can try to look through the code and attempt to understand it, and perhaps even, in time, debug it!

Thanks again!

Ghoser777 · Apr 25, 2006, 06:23 PM

The warnings are compiler errors, not runtime errors. Compiler errors just check things that might not be safe, but actually could be.

Wevah · Apr 25, 2006, 10:22 PM

What Ghoser said; those warnings could easily be gotten rid of in a few mintues.

The compiler doesn't really need to know whether those methods exist or not, though, since Obj-C method lookups happen at runtime.

I'm glad it's working for you, now, though!

Angus_D · Apr 26, 2006, 05:45 AM

Well, it looks like there might be some broken assumptions about return types there. Also, missing [super dealloc] will cause memory leaks.

Wevah · Apr 26, 2006, 09:28 AM

I admit I didn't read through all the warnings when I built it (since I didn't really care to use it), though the missing method declarations did strike me as a bit lazy.

...Although, the missing [super dealloc] ones are at the top.

I guess I'll just have to chalk it up to not caring at the time.

That code needs some fixup.

Thinine · Apr 26, 2006, 02:51 PM

When I was compiling this program, those errors were the result of including Foundation.h instead of Cocoa.h in the files. Switching the two let the program compile. Let me give this another go and I'll let you know.

ksloan2 · Apr 26, 2006, 03:54 PM

Weird, I replaced all references to Foundation.h with Cocoa.h as well, and it worked. I must Google as to why that is. I also added the [super dealloc] calls as suggested, and it compiled and seemed to work fine. Since I have no idea how to debug and check if they really were necessary, I'll leave them in just in case.

Wevah · Apr 26, 2006, 11:03 PM

What happens when you clean the target before building again? I still get the errors if I change the Foundation import to a Cocoa import (not that that's the issue, anyway).

Adding #import "MagicDocumentController.h" to MagicResponder.m does fix the issue, though.

Of course, some of those should be importing Cocoa (or AppKit) anyway, since they reference NSImage/NSWindow ....

ksloan2 · Apr 27, 2006, 04:57 AM

Thanks for that final tip! The project now builds without errors, except for the two warnings on the pointer/integer (NULL anyway) arguments which in the comments are explained as some "kiosk kung-fu", so I'll let those pass.

Could anyone explain what happens in Obj-C if you put too many [super dealloc] calls in? Does it cause any problems? After I put them in and the warnings went away, the program still behaved normally, so I hope it was OK.

Angus_D · Apr 27, 2006, 08:14 AM

Originally Posted by eobet

Could anyone explain what happens in Obj-C if you put too many [super dealloc] calls in? Does it cause any problems? After I put them in and the warnings went away, the program still behaved normally, so I hope it was OK.

This question doesn't make any sense. You should only put [super dealloc] where it's required - i.e. at the end of every dealloc method. Putting it in other places makes no sense, which would be "too many", and you'd end up freeing memory all over the place and causing the application to crash. If there is a dealloc method which doesn't have [super dealloc], it's almost certainly going to leak, so it has "too few" if you really want to put it like that.

Brass · Apr 27, 2006, 07:21 PM

Originally Posted by eobet

The missing a "super dealloc" sounds like it leaks memory somewhere. I wonder if this will permantently affect OS X over time unless I reboot?

Sort of, but not quite. The memory will be released when you quit the application. But it should be fixed to use [super dealloc] and avoid leaking.

ksloan2 · Apr 28, 2006, 06:38 AM

Originally Posted by Angus_D

This question doesn't make any sense. You should only put [super dealloc] where it's required - i.e. at the end of every dealloc method. Putting it in other places makes no sense, which would be "too many", and you'd end up freeing memory all over the place and causing the application to crash. If there is a dealloc method which doesn't have [super dealloc], it's almost certainly going to leak, so it has "too few" if you really want to put it like that.

Ah, very well. Since I've never used Obj-C I'm not familiar with the dealloc method. I suspect it's something like a destructor in C++, then. Anyway, I wonder why the original author missed adding the call.