Re: Linker warnings incorporating debug symbols from prelinked static library
Re: Linker warnings incorporating debug symbols from prelinked static library
- Subject: Re: Linker warnings incorporating debug symbols from prelinked static library
- From: email@hidden
- Date: Fri, 19 Sep 2014 11:42:39 -0700
The following is an explanation of, though not a solution to, your problem.
When we originally implemented DWARF on Mac OS X, one of the decisions we made was to not involve the linker in linking DWARF debug information. Instead, the DWARF is written into the .o files by the compiler, and all the linker does is write a "debug map" that tells either the debugger or dsymutil how to go from the linked binary to the .o file's debug info. Most importantly, none of the debug information is copied into the linked product.
Now a normal .a file is just a bag of .o files so the DWARF stays in the .o files as part of the .a file. Then when you link the .a file into your executable, all the debug information is still in place, and the debug map can point to the .o files in the .a file. But a "single object prelink" binary (i.e. something produced by "ld -r") is actually a product of the linker, not the ar tool. So it follows the same rule as other linker products, it gets a debug map pointing back to the .o files as they were when built. That means if you give somebody a binary of this sort without giving them the individual .o files, then dsymutil won't be able to link the debug info since it is still back in the .o files on your builder.
There isn't really a good solution for this at present. The obvious one would be for dsymutil to be able to make a "partially linked" dSYM out of the partially linked "ld -r" product which would then be fully linked when the "ld -r" library is linked, but it can't do that. You can file a bug requesting this, but I'm not sure it would ever get a very high priority, especially now that iOS 8 supports user frameworks.
You could give out a tar file with all the .o files along with the ld -r product - note that they would have to be untarred into the exact location they were when built for this to work. But that doesn't sound vary appetizing. If you make a .a file and then run ld -r on that, you only have to handle the .a file, if you don't mind giving out the .o files this is probably the most convenient way to do it. Again, the .a file would have to go in the same place it was on the builders for this to work.
Note also that switching from DWARF with dSYM to DWARF just means it is the debugger, not dsymutil, that can't find any of the debug information, so that's not a real solution.
I don't think there's any good way to use "single object prelink" to make a binary you are going to give out to folks and still keep the debug information intact.
Jim
> On Sep 19, 2014, at 10:38 AM, Jens Alfke <email@hidden> wrote:
>
> In my day job I develop a framework (Couchbase Lite) that's shipped as a static library for iOS.
> In the latest release, I changed the build process: enabling "single object prelink", making symbols private by default, and using an exported-symbols file so that only the symbols in the public API are visible.
>
> The problem is that developers are now reporting that when they build their apps that import this library, they get 160 linker warnings of the form:
>
> warning: (arm64) /Users/jenkins/jenkins/workspace/build_cblite_ios_102-community/couchbase-lite-ios/build/CouchbaseLite.build/Release-iphoneos/CBL iOS library.build/Objects-normal/arm64/CBL_Revision.o unable to open object file
>
> (CBL_Revision.o is the object code of a source file in the library, and the long path is apparently where it's located when our automated build server builds the library. There's one of these warnings for each object file from the library.)
>
> Developers have reported that the warnings can be suppressed by changing their applications' Build Setting Debug Information Format from "DWARF with dSYM file" to "DWARF". But this isn't a perfect workaround, because doing so makes the app incompatible with the popular Crashlytics service.
>
> I've tried changing the library target between DWARF and DWARF-with-dSYM, and changing the symbol-stripping options to not strip debug symbols, but it doesn't make any difference.
>
> Anyone know how to resolve this? To be specific:
> * This is an iOS static library, to be linked into 3rd party apps.
> * The apps should incorporate sufficient debug symbols from the library so that library method names will show up in backtraces, crash reports, etc.
> * And there shouldn't be hundreds of link warnings :)
>
> —Jens
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden