We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1754

Summary: Link SDL_image HG to Cocoa
Product: SDL_image Reporter: dfyx+libsdl.org
Component: miscAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: major    
Priority: P2 CC: dfyx+libsdl.org, josh+sdl
Version: unspecified   
Hardware: All   
OS: Mac OS X (All)   

Description dfyx+libsdl.org 2013-03-13 10:56:18 UTC
I tried building HG revision 3d002acf103d version of SDL_image on Mac OS X (Mountain Lion x86_64 but I guess this applies to all versions) and I got the following linker error:

  "_objc_msgSend_fixup", referenced from:
      l_objc_msgSend_fixup_autorelease in IMG_ImageIO.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

A little google research showed that this symbol appears to be defined by Cocoa so adding "-framework Cocoa" to the linker flags should do the trick. Sadly I'm not experienced enough with autoconf/automake to update the makefile myself. Otherwise I'd have included a patch.
Comment 1 Sam Lantinga 2013-06-03 00:03:35 UTC
I just tried here and had no problems.  I did notice that libSDL2_image.la had -lobjc in the dependency libraries, and that might be required for you.

Are you building using the Xcode projects or command line?  What version of either Xcode or autotools are you using?
Comment 2 Joshua Root 2013-08-13 00:57:07 UTC
I'm seeing this with the 2.0.0 release. OS X 10.7.5, Xcode 4.6.3, building with autotools.

The exact failing command is:

libtool: link: /usr/bin/clang -dynamiclib  -o .libs/libSDL2_image-2.0.0.dylib  .libs/IMG.o .libs/IMG_bmp.o .libs/IMG_gif.o .libs/IMG_jpg.o .libs/IMG_lbm.o .libs/IMG_pcx.o .libs/IMG_png.o .libs/IMG_pnm.o .libs/IMG_tga.o .libs/IMG_tif.o .libs/IMG_xcf.o .libs/IMG_xpm.o .libs/IMG_xv.o .libs/IMG_webp.o .libs/IMG_ImageIO.o   -L/opt/local/lib /opt/local/lib/libSDL2.dylib  -arch x86_64 -Wl,-headerpad_max_install_names -arch x86_64 -Wl,-framework -Wl,ApplicationServices   -install_name  /opt/local/lib/libSDL2_image-2.0.0.dylib -compatibility_version 1 -current_version 1.0 -Wl,-single_module
Undefined symbols for architecture x86_64:
  "_objc_msgSend", referenced from:
      _Create_SDL_Surface_From_CGImage_Index in IMG_ImageIO.o
  "_objc_msgSend_fixup", referenced from:
      l_objc_msgSend_fixup_autorelease in IMG_ImageIO.o
ld: symbol(s) not found for architecture x86_64

So it definitely seems to be missing a -lobjc.
Comment 3 Sam Lantinga 2013-08-13 01:16:54 UTC
Interesting, I'm not seeing this.  I thought at first it might be gcc vs clang, but it still works for me with clang:
libtool: link: clang -dynamiclib  -o .libs/libSDL2_image-2.0.0.dylib  .libs/IMG.o .libs/IMG_bmp.o .libs/IMG_gif.o .libs/IMG_jpg.o .libs/IMG_lbm.o .libs/IMG_pcx.o .libs/IMG_png.o .libs/IMG_pnm.o .libs/IMG_tga.o .libs/IMG_tif.o .libs/IMG_xcf.o .libs/IMG_xpm.o .libs/IMG_xv.o .libs/IMG_webp.o .libs/IMG_ImageIO.o   -L/usr/local/lib /usr/local/lib/libSDL2.dylib -lm -liconv -lobjc  -Wl,-framework -Wl,ApplicationServices   -install_name  /usr/local/lib/libSDL2_image-2.0.0.dylib -compatibility_version 1 -current_version 1.0 -Wl,-single_module

Notice that there's -lobjc in the link line, coming from libSDL2.la.

What are the contents of /opt/local/lib/libSDL2.la?
Comment 4 Joshua Root 2013-08-13 13:58:12 UTC
OK, that would be the difference then. We clear out the .la files in MacPorts because they can cause pretty massive overlinking*. Relying on dependency_libs to give you libs that you use directly is incorrect in any case.

* See e.g. https://wiki.debian.org/ReleaseGoals/LAFileRemoval
Comment 5 Sam Lantinga 2013-08-14 03:14:18 UTC
What's the correct way to express those dependencies?
Comment 6 Joshua Root 2013-08-14 11:39:23 UTC
If you use a lib directly, you just need to explicitly link against it.

You only need dependency_libs for dynamic linking on platforms where the linker can't track dependencies, which is generally only really old or obscure platforms. The fact that it's still used on platforms with smarter linkers is a misfeature in libtool (at least in my opinion and that of many distro maintainers). The libtool devs have basically said, "patches welcome, but make sure you don't break portability, which may be harder than you think."
Comment 7 Sam Lantinga 2013-09-07 06:57:28 UTC
Okay, this should be fixed.
http://hg.libsdl.org/SDL_image/rev/361ab0371a02
Thanks!