Xcode Linker Errors

[maaaaark]

I am updating our game engine to Cocoa, and I'm running into a problem linking with JPEG libraries. The JPEG framework (with the standard JPEG code) compiles perfect. I include the framework with the framework that uses it (call it ImageFramework). ImageFramework gives me linker errors (compiles fine, but errors when linking), with some nice undefined symbols:

ld: Undefined symbols:
_jpeg_CreateDecompress
_jpeg_destroy_decompress
_jpeg_finish_decompress
_jpeg_read_header
_jpeg_read_scanlines
_jpeg_start_decompress
_jpeg_std_error
_jpeg_stdio_src
/usr/bin/libtool: internal link edit command failed

These functions are very much defined. Help? :cry:

[maaaaark]

Okay, I found the problem, but this may morph the original question into an entirely new question :) Using Cocoa, I had to compile the libjpeg.dylib that I had fink nicely install for me. It compiles/links fine.

New question:
Why the heck did I have to do this extra step? The carbon version of this engine worked fine, without having to link with libjpeg.dylib. I'm also under the impression that the code in libjpeg.dylib is 80% identical to whats in my JPEG.framework that I compiled.

(Usign Seinfeld impression)What's the deaaaal?

[OneSadCookie]

It sounds like you're a bit confused :p

a) declared != defined -- just having the header isn't enough
b) you almost certainly don't want to link to libjpeg.dylib, 'cos then your customers will have to have the same file installed in /usr/lib or the same place you have it
c) you almost certainly /do/ want to link to libjpeg.a -- and Xcode/gcc will always link to a .dylib in preference to a .a if one exists.
d) make sure your library search paths are pointing where you think they are; Xcode does a poor job of managing them
e) why the heck do you want to build a perfectly good .a file into a framework anyhow?

[maaaaark]

b/c), Well since I had to compile libjpeg.X, I don't expect the majority of users to have this in their /usr/lib. I will be bundling inside my app (~ 156k).

e) What are the advantages of the different types (.a .dylib .framework). I was toying with the idea of turning all of the libraries into .a files if possible. I only went the .framework path, since the predecessor code that I was working with was going this route. On the PC, they dynamically load these .dll files on load time. On the Mac, I was just loading the .frameworks.

[maaaaark]

Also, I'd like to add that it is reading SOME functions of JPEG.framework, but not the _jpeg_* (listed above) ones. So it HAS to be reading the JPEG framework okay (well.. maybe not HAS to, but I'm assuming here :))

[arekkusu]

It looks like all you're doing is uncompressing JPEG images (not messing with the EXIF header.) So, why are you using a 3rd party library at all? If you're updating to Cocoa, use a standard Apple-provided library: Quartz or QuickTime.

[maaaaark]

I want to also note that Xcode is calling the functions:

_jpeg_function_name

when they are really:

jpeg_function_name.

Why is it adding that underscore? I think this is a symptom of the real problem. Could linking against Cocoa frameworks cause something like this (not the underscore, but the error in general).

-----------
Reponse to arekkusu:
Just to be identical with the PC version. Besides, why take the time to write mirrored QuickTime functions if this route works (well.. I guess WORKED) already? Besides, thats one less identical file to the PC version of the engine. I'd like to maintain as much symmetry as I can.

[arekkusu]

I see. You said you were updating to Cocoa, I thought that meant you were Mac-only.

The leading underscore is normal, nothing to worry about.

[maaaaark]

Why oh why couldn't Apple go C++ :'( I'm not bashing on Objective-C at all, but for games... eh.. :)

[OneSadCookie]

functions in .a files are linked into your application's binary.