Bug 13554 - weak_import attribute and -no-undefined libtool option are incompatible (unresolved symbol on tiger)
Summary: weak_import attribute and -no-undefined libtool option are incompatible (unre...
Alias: None
Product: cairo
Classification: Unclassified
Component: quartz backend (show other bugs)
Version: 1.5.5
Hardware: x86 (IA32) Mac OS X (All)
: medium normal
Assignee: Vladimir Vukicevic
QA Contact: cairo-bugs mailing list
Keywords: patch
Depends on:
Reported: 2007-12-06 17:32 UTC by Brian Tarricone
Modified: 2008-10-10 14:59 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

allow-undefined.diff (444 bytes, patch)
2007-12-06 22:25 UTC, Brian Tarricone
Details | Splinter Review
cairo-panther-weak_import.patch (748 bytes, patch)
2007-12-19 02:54 UTC, Anders F Björklund
Details | Splinter Review

Description Brian Tarricone 2007-12-06 17:32:15 UTC
Trying to compile git as of < 1 hour ago, I see:

ld: Undefined symbols:

Apple says 10.5 and later:

I'll try to cook up a patch; I don't see why you couldn't emulate DrawTiledImage() with several calls to DrawImage() (though perhaps this approach doesn't perform as well).
Comment 1 Brian Tarricone 2007-12-06 22:25:45 UTC
Created attachment 12990 [details] [review]

Ok, just learned about __attribute__((weak_import)).  However, it looks like this use is incompatible with -no-undefined.  Patch removes it from Makefile.am.
Comment 2 Erik van Pienbroek 2007-12-16 12:26:04 UTC
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.
Comment 3 Brian Tarricone 2007-12-16 14:43:32 UTC
(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.
Comment 4 Anders F Björklund 2007-12-19 02:54:26 UTC
Created attachment 13215 [details] [review]

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...
Comment 5 Wim Lewis 2007-12-21 17:35:02 UTC
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.
Comment 6 Erik van Pienbroek 2008-04-29 09:34:40 UTC
Isn't this bug already fixed in commit ea9afecc9aaa87c2df14dc9126c75ac0e3e5b13f ([quartz] Do dynamic symbol lookups for 10.4/10.5 optimization symbols) ?
Comment 7 Brian Tarricone 2008-04-29 10:41:09 UTC
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...
Comment 8 Chris Wilson 2008-10-10 14:59:30 UTC
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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.