iPhone mangled symbol size explosion in release
We're currently working to ship an iPhone application that makes heavy use of Boost. The compiled executable is absurdly large, partly to third party libraries, partly to our own insufficent coding practices, but strikingly it seems that (from looking at the executable in a hex editor) around 4MB of the 9.5MB app size is mangled boost function names. We are statically linking against the libraries in Boost we are using. Here are some examples: __ZN5boost13serialization9singletonIN S_7archive6detail11oserializerINS2_12 xml_oarchiveEN6newton18Vector3InitializerEEEE12get_instanceEv __ZNK5boost6spirit8sequenceINS1_INS1_ INS0_6strlitIPKwEENS0_4ruleINS0_7scan nerIN9__gnu_cxx17__normal_iteratorIPc SsEENS0_16scanner_policiesINS0_16iter ation_policyENS0_12match_policyENS0_1 3action_policyEEEEENS0_5nil_tESI_EEEE NS0_5chlitIwEEEENS0_6actionISJ_NS_7ar chive3xml11assign_implISsEEEEE5parseI SH_EENS0_13parser_resultISU_T_E4typeERKSX_ AFAIK All application functions should have been hard-linked since we're statically linking and thus not require any type of named reference. Am I perhaps missing or misusing a Boost configuration setting or compiler flag? Thanks, Michael Marcin
Michael Marcin wrote:
We're currently working to ship an iPhone application that makes heavy use of Boost. The compiled executable is absurdly large, partly to third party libraries, partly to our own insufficent coding practices, but strikingly it seems that (from looking at the executable in a hex editor) around 4MB of the 9.5MB app size is mangled boost function names. We are statically linking against the libraries in Boost we are using. Here are some examples:
__ZN5boost13serialization9singletonIN S_7archive6detail11oserializerINS2_12 xml_oarchiveEN6newton18Vector3InitializerEEEE12get_instanceEv [...]
AFAIK All application functions should have been hard-linked since we're statically linking and thus not require any type of named reference.
Am I perhaps missing or misusing a Boost configuration setting or compiler flag?
There was a recent change to Boost.Build that changed the default behavior of symbol stripping for the built-in release variant (in trunk). It now no longer strips symbols by default. And one needs to add a "<strip>on", and conversely <strip>off, to have the previous default functionality. And it also happens that I just checked in changes to fix the darwin/xcode toolset that accounts for the new "strip" feature, specifically because I also have to strip for the sake of creating the smallest binaries possible on the iPhone. Note, please direct further discussion of this to the Boost.Build list (CC'd here for tracking). HTH. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Hello Michael,
We're currently working to ship an iPhone application that makes heavy use of Boost. The compiled executable is absurdly large, partly to third party libraries, partly to our own insufficent coding practices, but strikingly it seems that (from looking at the executable in a hex editor) around 4MB of the 9.5MB app size is mangled boost function names. We are statically linking against the libraries in Boost we are using. Here are some examples: __ZN5boost13serialization9singletonIN S_7archive6detail11oserializerINS2_12 xml_oarchiveEN6newton18Vector3InitializerEEEE12get_instanceEv __ZNK5boost6spirit8sequenceINS1_INS1_ INS0_6strlitIPKwEENS0_4ruleINS0_7scan nerIN9__gnu_cxx17__normal_iteratorIPc SsEENS0_16scanner_policiesINS0_16iter ation_policyENS0_12match_policyENS0_1 3action_policyEEEEENS0_5nil_tESI_EEEE NS0_5chlitIwEEEENS0_6actionISJ_NS_7ar chive3xml11assign_implISsEEEEE5parseI SH_EENS0_13parser_resultISU_T_E4typeERKSX_ AFAIK All application functions should have been hard-linked since we're statically linking and thus not require any type of named reference.
Am I perhaps missing or misusing a Boost configuration setting or compiler flag?
An update for anyone that might run across this thread in a future archive search. Problem may be solved. Apparently there is another switch in Xcode, called "Deployment Postprocessing", which, if not turned on, means all the other settings there (like strip symbols) are completely ignored. Damned "intuitive" IDEs. App goes to 4.7Mb from over 9Mb. Thanks, Michael Marcin
participants (2)
-
Michael Marcin -
Rene Rivera