2

I'm creating a .component bundle on MacOSX with xCode 7. I'm trying to get rid of all debugging symbols and library symbols for release configuration. I set all suitable options in xCode (like Strip Debug Symbols, Strip style to all symbols, symbols hidden by default etc.)

Unfortunately there are still some symbols visible in compiled and linked component file.

So I use strip -x -S mybundle.component to remove them externally. And it almost work but not for lambdas callers. If any of method is using lambda expression, resulting binary has it names and all the callees and callers till lambda itself in linker "semi-obfuscated" style like ZN18MyClassName8MetodNameEP9BSFirstParamP7SecondParamE3$_1 So it looks like a linker issue?

As an example, some code:

class AClass {

   public:
       void methodCallingCallbackInTheEnd();
       std::function<void(C*, D*)> myCallback;
}

class BClass {

   AClass a;
   CClass *c;
   DClass *d;

   public:
       methodOfClassB() {  
          a->callback = [c,d] (C* c, D* d) {
              //do something with c and d objects
          };

          a->methodCallingCallbackInTheEnd();
       }
}

class EClass {
    public:
        EMethodNotVisibleInBinary();
}

So, as an effect of compiling and linking, I can see in binary some entries for A and B class, even with parameter types of C and D like that:

ZN18AClass8callbackE34$_2

then next some info about the callback itself, like:

ZN18BClass8methodOfClassBEP9BSCClassP7DClassE3$_1

Is there any way to get rid of them? Why they appear at all? EClass, EMethodNotVisibleInBinary etc. are not visible of course. There are no such strings in .component file.

It's very important to me and I don't want to obfuscate that parts of course.

Any ideas?

mqqla
  • 39
  • 2
  • Please give a testcase that we can actually compile... – Marc Glisse Jan 14 '16 at 18:20
  • Why do you care? Are you worried that somebody is going to reverse engineer your code? The fully optimized build is not going to be easier to de-compile because of a few lambda symbols. – Martin York Jan 14 '16 at 18:23
  • If you are building a dynamic library, you need *some* symbols. – n. 1.8e9-where's-my-share m. Jan 14 '16 at 19:19
  • Why do I care? Because those names are vital for my license management and they persist there. @MarcGlisse Cannot prepare test case - when trying to prepare such - it has no symbols at all with the same xCode settings for release. – mqqla Jan 14 '16 at 20:57

0 Answers0