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.

This is fixed in subversion, thanks!

This patch will cause breakage elsewhere, specifically in packages that use autoconf (at least older versions of it, which are not aware of the "framework" option).

Using -Wl,framework,Cocoa is an alternate way to pass the "-framework Cocoa" option directly to the linker, but has the advantage of not requiring tools such as autoconf to know that the two command line words "-framework" and "Cocoa" need to be grouped. Without this "trick", older autoconf versions will separate the two and thus mess up the compile/link process.

Note that "-Wl" is *specifically* there to pass options to the compiler. Whatever the real issue here is, it shouldn't be the use of -Wl... unless maybe some funk special compiler is being used?

More information on the issue would be helpful:

* What version of OS X is this on?

* Which compiler version, which version of XCode?

* If your code is available as open source, maybe you can point us to your repository for further tests?

I need to correct myself: The issue is in libtool, not in autoconf. Anyway, it seems 10.5 ships with a libtool version supporting -framework -- no idea about 10.4. However, this doesn't help applications built with autoconf, as they will use the libtool (rather, ltmain.sh) version included with them. 

It is still not clear to me whether the changes from commit 4785 actually fix the issue seen by Matej.

Note that -Wl has worked fine for me over many years in tons of different SDL projects on all OS X versions so far.

I just verified: The libtool version (1.5) shipped with Mac OS X 10.4 does *not* support -framework correctly.

Ugh, okay, I'll revert this change then, since it's not safe for 10.4.

OK, the project's name is DevIL (openil.sf.net) and the discussion with the affected person can be viewed here:
https://sourceforge.net/projects/openil/forums/forum/13560/topic/2647208
Probably only last posts (especially config.log) are interesting for you.

I use the AM_PATH_SDL macro and then basically pass $SDL_LIBS to foo_la_LDFLAGS in Makefile.am

The build process of DevIL is quite complex so I only explain this briefly, but I can provide further info if needed.

If you would like to, you can check out a branch and test it whether it builds or not. If this is the case, check out the code, run "autoreconf -i" in the directory where configure.ac is and pass "--enable-ILUT" to the configure script. Then just run make and that's it.
You may want to pass also --disable-<foo> to the configure script since some part of DevIL may cause problems, but now you only want to know whether SDL stuff can get built.

You need new versions of autotools, though.

svn ci https://openil.svn.sourceforge.net/svnroot/openil/trunk/DevIL devil

OK, so I followed your instructions, and everything compiled and linked just fine, with SDL 1.2.13 and also with SDL trunk (with the "-framework" patch removed).

Next I tried
  ./configure --enable-ILU --enable-ILUT --with-examples
as suggested in the bug report thread you mentioned. With that, I *did* get a linker error. I'll investigate to find out why.

Side remark: I had to modify src-ILU/ilur/ilur.c to get things to compile -- it #includes malloc.h, which is incorrect and not portable (malloc() is declared in stdlib.h, while malloc.h is a system dependent file, containing kernel related stuff on many unix systems).

OK, here's what I discovered: Ancient libtool (say v1.5 and old) did not support "-framework FOO" and would garble it. As a workaround, we used "-Wl,-framework,FOO" which got passed unchanged to the linker.
Later libtool versions (say 1.5.X for X big enough) added explicit support for -framework, so you now could use both approaches

In current libtool (I am looking at 2.2.6), the support for -framework is fancy and elaborate, so far that if it is used, then libtool recognizes that it is an option relevant to linking, and adds it into library .la files it creates as an inherited dependency! 
This elaborate logic fails when using -Wl. Hence the failure in the report, because the ILUT_sdl program does not link explicitly against SDL.

However, this means there is a simple portable (I believe) solution: Use SDL_LIBS explicitly (contrary to your last comment, matej, it isn't currently being used anywhere as far as I can tell ?). Changing 
  ILUT_sdl_LDFLAGS = $(ilut_library)
to
  ILUT_sdl_LDFLAGS = $(SDL_LIBS) $(ilut_library)
in bin/Makefile.am resolves the issue, now things work with -Wl *and* with -framework.

Okay, I reverted the SDL change. Thanks for looking into this Max!

Thank you for your reply and especially for that malloc suggestion!

I also apologize for not so precise instructions (it has been a while), but you seem to be pretty skillful ;-)
I think that I understand that, you want me pass SDL flags to any apps using ILUT and SDL not relying on libtool. Just FYI, SDL_LIBS are used in DevIL in the way that they become part of ILUT_LIBS in the configure script (see config.log) and they are output to the lib/Makefile.am file.

Concerning this issue, it would be pity not to use features of "new" libtool, I think that you can actually remove the workaround without worrying too much about breaking too many of packages. I also guess that SDL changed a little bit over that time, so these old packages need some revisions anyway.
I don't insist that you do it now, but when you release a new version, I would advise to change the behavior. What do you think?

Thanks,
Matej

Disclaimer: The following is just my personal opinion, I am not an SDL developer.

I agree that it would be nice to be able to take advantage of this libtool 2 feature. And I believe that SDL 1.3 (or maybe 2.x? :) should dare to switch from the -Wl style to -framework -- after all, it's forward looking and under development, and new software should use either libtool 2, or  a recent libtool 1.x version (e.g. 1.5.22 as shipped on 10.5). Even if people develop software on OS X 10.4, it is easy to install a recent GNU libtool version (manually, or via Fink, via MacPorts, etc.). So, I believe it will be safe to switch to -framework, since anything using SDL 1.3 is being developed today, and thus has access to those modern tools.

But SDL 1.2.14 might be the last SDL 1.2.x release ever, and I strongly believe that it should try not to introduce regressions, esp. as those might not be resolved later on. 

So, in short, my recomendation is this: Let SDL 1.2.x stay as it is (even though it causes some inconvenience for DevIL / ILUT and maybe some other folks -- sorry about that). And let's move forward with SDL 1.3 to the new system.

Dear Max,
I agree with you, if the situation with SDL releases is like you have just described, it makes sense not to change things in the current SDL line.

But new SDL should IMHO have something better to support its usage . I will add another tracker item about it, though.