Linker error when using libPNG

[TomorrowPlusX]

So, I'm migrating my textures from TGA to PNG, using some of OSC's libPNG sample code. I feel more comfortable with using libPNG since the code is legible and makes sense, whereas Quicktime scares me a little. Before anybody flames me about Quicktime, I've written code for my robotics work which encodes a quicktime moview from OpenGL output. I know Quicktime, enough, and I don't like its design... and I want the core of my game's engine to be as portable as possible.

I couldn't find libPNG in /usr/lib or /usr/local/lib so I built my own ( to libpng.a ) from source with the intent to statically link it to my executable.

Then, I wrote a GLUT testbed to make certain I could use it and it works fine, in the testbed.

But, when I attempted to migrate my game over, I got linker errors which seem to imply a symbol conflict with AppKit.

here's the output:


Ld /Users/zakariya/Projects/Legion/build/Legion.app/Contents/MacOS/Legion
cd /Users/zakariya/Projects/Legion
/usr/bin/g++-3.3 -o /Users/zakariya/Projects/Legion/build/Legion.app/Contents/MacOS/Legion -L/Users/zakariya/Projects/Legion/build -Llib -L/Users/zakariya/Projects/Legion/lib -F/Users/zakariya/Projects/Legion/build -Flib -filelist /Users/zakariya/Projects/Legion/build/Legion.build/Legion.build/Objects-normal/Legion.LinkFileList -framework Cocoa -framework Carbon -framework GLUT -framework OpenGL -lGLEW -lode -lftgl -lfreetype -framework PANSICore -lz -lpng -arch ppc -prebind -Wl,-no_arch_warnings -lmx
ld: multiple definitions of symbol _png_get_uint_31
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit(single module) definition of _png_get_uint_31
lib/libpng.a(pngrutil.o) definition of _png_get_uint_31 in section (__TEXT,__text)



Can anybody tell me what's going on? If AppKit already has a libPNG is there any way to just use its version instead of my own?

[Steven]

If it does have it, then you could just not link with libPNG and AppKit would provide you with the methods you need. If it does not have it compiled in, you will get more linker errors. Try it!

[TomorrowPlusX]

I tried a number of approaches, and I never was able to trace why libPNG worked in my GLUT testbed ( which links against Cocoa ) and not my game itself ( which is C++ but uses a cocoa shell, adapted from OSC's GameShell )

So, I'm using Quicktime ;)

The good news here is that it looks like I can resize an image using quicktime before reading the bytes out -- which is good since my terrain system optionally downsamples a high-res heightmap ( currently using NSBitmapImageRep), so you can have "quality" levels.

if I can do the same using Quicktime, I can eliminate some code duplication in my game.

[AnotherJake]

I'm guessing the _png_get_uint_31 issue has something to do with the libpng security update in 10.3.5. AppKit and CoreGraphics both use libpng. It seems like it wasn't very friendly of Apple to do it that way but oh well. It's better to be using QT anyway, and this is a good example of why. Using QT or other system frameworks makes sure that security updates like this one are centralized and effective for *all* apps out there that use it.

[TomorrowPlusX]

The advantage also is that I can load JPGs too, which is good since my terrain textures don't need alpha and look fine even with lossy compression.

Anyway, I gave a stab at using CoreGraphics to load PNGs and JPGs, but that didn't work out. Too bad, since CoreGraphics is better documented and I find the API all together to be more palatable than Quicktime.

If anybody here knows anything about CoreGraphics, I'd like you to pick over my code and tell me why it doesn't work... I'll post later. I'm at work ;)