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 15:23:52 -0700
> On Sep 19, 2014, at 1:49 PM, Jens Alfke <email@hidden> wrote:
>
>
>> On Sep 19, 2014, at 11:42 AM, email@hidden wrote:
>>
>> 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.
>
> Thanks for the info, Jim. The single-object prelink is just a means to an end; my main goal was to keep the non-public symbols in the library from colliding with symbols in client apps. (Specifically, a developer was having problems because their app uses the yajl library, and so does Couchbase Lite, and linking their app produced duplicate-symbol errors for all the yajl functions.)
>
> Is there any way to turn off single-object prelink but still keep the private symbols in the library from colliding with app symbols? I suspect the answer is "no", because the private symbols would have to remain visible enough for one of my .o files to find a symbol from another of my .o files, which probably means it'd be visible to an application's .o file too…
Yes, I am pretty sure all the .o files are treated as a flat namespace where everything but file-statics are visible. So I can't see another way you could do this. If you were using C++ you'd use a namespace for this. Otherwise you're stuck with the obnoxious_function_prefix method of making a namespace...
Jim
>
>> 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.
>
> I'm very glad iOS 8 is supporting real frameworks, even if it took adding app extensions to make it happen (not just the fact that library developers' lives are a living hell without them.) Sadly, it's going to take another year or so before we can make our library require iOS 8.
>
> —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