#Symbolic linker os10.9.5 mac os x#
#Symbolic linker os10.9.5 full#

#Symbolic linker os10.9.5 mac os x#

The computer is a fresh (not upgraded) Mac OS X 10.9 + Xcode (5.0.2) with command line tools I think the problem is the linker, so I post here again. When ld gets to those libraries, it adds them to its list (if they’re not already there), but somehow the SDK path doesn’t get prepended, so it just uses the verbatim path.Bq. That is, I link to one dylib and it has some other libraries listed in its dependencies. It turns out that the linker’s failure to stay in the SDK tree is caused by the resolution of 2nd-level dependent libraries. I peppered the sources with extra printf statements just so I could figure out what was happening when. At least I can take a look at what is supposed to happen, if not necessarily fixing the problem. Thanks to Darwin, I find myself downloading and building my own copy of ld. In no case should a library be used from “/” when a perfectly good counterpart exists in the SDK tree. So I don’t think it’s too far out of line for me to believe that the log line shown above is a sign of a bug in ld.

#Symbolic linker os10.9.5 full#

What’s supposed to happen here is that the provided path gets prepended to all full path library references, and that path is given priority in the search. But what causes this? I’m specifying the SDK path with the “-isysroot” parameter to the gcc, which in turn ends up getting passed as a “-syslibroot” parameter to ld in the link phase. Used dynamic library: /usr/lib/libSystem.B.dylibĪha! So at least I know why it’s got its head screwed on wrong.

When I did so, I was surprised to see it confess openly just how many libraries it was pulling in from my root system, instead of from the SDK. Set the environment variables LD_TRACE_ARCHIVES and LD_TRACE_DYLIBS to encourage ld to spit out some potentially useful information. If you find yourself in a similar boat, there are some debugging aids you should know about. But why!? And do I really have to start debugging the linker? Which implies that the linker is looking in my OS instead of the SDK, when trying to resolve these symbols. Apple has changed the inter-framework dependencies at some point, such that my OS (10.4.8) is not compatible with my 10.4 Universal SDK. Looking at my installed system, however, I discover that these symbols are completely absent. CarbonCore wants some _acl symbols, and libSystem has them. My SDK’s CarbonCore and libSystem are in perfect agreement. Getting bored yet? Let me cut to the chase. % nm CarbonCore | grep _acl_copy_ext_native That’ the situation that CarbonCore is in: If a file only has Us for a given symbol, it’s going to look elsewhere for resolution. It’s OK for a single binary to have both U and T symbols, because the file will resolve against itself.

It actually means “Text Section Symbol,” but what’s important is it’s a symbol for code, not a symbol for an undefined import, like the U right above it. See the capital T? That means “implemented” to you. % nm usr/lib/libSystem.dylib | grep _acl_copy_ext_native Just to get my head on straight I decided to confirm that that SDK’s version of libSystem had the symbols that are allegedly “undefined”: After scouring the makefiles (in this case it’s the Subversion project), looking for unwanted -L or -F flags that would point the build process back into an unwanted directory, I’m left empty-handed. I am using SDKs (-isysroot from the command line), so maybe I’ve given the linker mixed signals about where to search for libraries. Still, I need to make sure I’m not leading the linker astray somehow. The disagreement between two of Apple’s low-level frameworks is a great tip that this isn’t really my problem. _task_name_for_pid referenced from CarbonCore _acl_copy_int_native referenced from CarbonCore _acl_copy_ext_native referenced from CarbonCore Still, you have to wonder when you stare down a perplexing “undefined symbols” error, which you can’t for the life of you imagine being accurate: These tools are used by just about every shipping binary executable inside or outside of Apple, so chances are they’ve gotten all of the really critical bugs ironed out. Usually we get to take compiling and linking for granted. It’s not due until tomorrow, but what’s this? The linker’s failing? OK, I designed the architecture of the project. If you’re anything like me, the most challenging part of your development is when the process itself doesn’t seem to be working. Special thanks to Eric Albert for patiently showing me the error of my ways. Followed by a mea culpa explaining that I’d gotten it all wrong. Summary of this post: long, boring analysis of how I thought I was tracking down a bug in ld. Update: I shouldn’t be so trigger-happy with blog entries.