Re: C++ name collisions between plugins
Re: C++ name collisions between plugins
- Subject: Re: C++ name collisions between plugins
- From: Darrin Cardani <email@hidden>
- Date: Tue, 12 Nov 2013 09:47:30 -0800
Paul,
Did you ever get this resolved? If not, I’ve got some questions below.
On Nov 6, 2013, at 1:52 PM, Paul Miller <email@hidden> wrote:
>
>> Have you run
>> nm -a
>> On the resultant binary to make SURE that the requisite structures/classes are hidden?
>>
>> I've found that symbols are not necessarily hidden unless you hide the symbols upon compile (using the hidden flag for visibility), and THEN also strip the binary afterwards.
> Coming back to this again - now I have another plugin that has the same strip settings (and related symbols file) as the previous one that appeared to work, although now the two new ones are colliding.
I’m still confused on how C++ code is having name collisions. Did we ever determine why that’s happening? Normally, C++ doesn’t have this problem, just Objective-C.
>
> These are the settings I am using:
>
> Linking:
> Exported Symbols File: symbols.txt
>
> symbols.txt contains an entry for each filter class initialization function:
>
> [FilterClass1 initWithAPIManager:]
> [FilterClass2 initWithAPIManager:]
>
> However, when I run "nm" on the resulting binary, these symbols are marked "t", which I believe is internal.
“t” indicates the symbol is local and part of the “Text” section.
> Pete mentioned also running "strip". I tried running it with -u -s symbols.txt and that didn't help.
>
> Assuming I have this symbols.txt file with the blessed list of filter class entry points, is there a single "strip" command that will hide everything else?
I don’t know a lot about how strip works, so I’ll have to ask internally about it.
Darrin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden