Bug 13554

Created attachment 12990 [details] [review]
allow-undefined.diff

Ok, just learned about __attribute__((weak_import)).  However, it looks like this use is incompatible with -no-undefined.  Patch removes it from Makefile.am.

The removal of the '-no-undefined' flag doesn't really help. All cairo dependent packages will now fail to start due to the missing _CGContextDrawTiledImage function on Tiger.

(In reply to comment #2)
> The removal of the '-no-undefined' flag doesn't really help. All cairo
> dependent packages will now fail to start due to the missing
> _CGContextDrawTiledImage function on Tiger.

Not the case for me.  I'm on Tiger, and cairo-using apps work just fine with my patch.  Suggest you look up how weak_import works with Apple's gcc.

Created attachment 13215 [details] [review]
cairo-panther-weak_import.patch

The Intel build worked (since it is 10.4+ by default), but I never could get the PowerPC build to work (since I am using 10.3+ for that) - so I ended up just disabling the CGContextDrawTiledImage optimization when compiling with the SDK...

I think what we're seeing here is a subtle incompatibility between weak_import symbols and two-level namespaces (the default on OSX). Apple's docs don't really spell it out, but it appears that with two-level namespaces, weak symbols must be bound to a particular dylib (or framework) at *link* time, even if their specific address (or lack of address, for weak_imports) is not determined until run time. As a result, you can't use weak_imports to deal with symbols which aren't there when you're compiling the program but which might be there when you're running it --- only for the opposite situation, for symbols which are available when compiling but might be missing from the dylib when running the program. From Apple's point of view, you're only expected to compile on the most recent release which you intend to use features from.

A bunch of possible solutions:

1. Switch to flat namespaces instead of two-level namespaces, which would allow the use of "-U _CGContextDrawTiledImage" when linking.

2. Use "-undefined dynamic_lookup" to, in effect, make all undefined symbols weakly bound. This is what Brian Tarricone's patch does, but as he notes, it prevents the linker from warning us about truly undefined symbols, which could conceal real problems.

3. Look up the CGContextDrawTiledImage function by hand using the NSModule(3) API and stash it in a function pointer. This is effectively what the linker is doing for us if we were to use "-undefined dynamic_lookup", except only for the one symbol we want it to. I've done this on other projects and it seems to work fine.

4. Disable the use of CGContextDrawTiledImage() if compiling on 10.4 or previous, even if running on 10.5 (but when compiling on 10.5+, still produce a weak reference so the program can run on older versions). This is what Anders F Björklund's patch does.

5. Use approach #3 when compiling on old systems, #4 on 10.5.

Isn't this bug already fixed in commit ea9afecc9aaa87c2df14dc9126c75ac0e3e5b13f ([quartz] Do dynamic symbol lookups for 10.4/10.5 optimization symbols) ?

Not sure -- I haven't tried to build this in quite a while on 10.4.  If the commit message does what I think it does, I'd imagine it is indeed fixed, though...

I know that Vlad has been pretty thorough on identifing and fixing OS/X 10.4 vs 10.5 issues, so I'll take the commit to fix this at face value - if the problem still exists in 1.8.0, please reopen.