Symbol stripping on OS X

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/09/2012 at 09:57, xxxxxxxx wrote:

Howdy,

Originally posted by xxxxxxxx

...To edit the scheme settings, press ALT-Cmd-R (or use the menu: Product -> Edit Scheme...). There you can switch between release, debug, etc...

Thanks. I did figure that out by googling it, and discovered that it was set to "Release":

Is there some other setting that needs to change, that's causing the "stack_chk_guard"?
I'm still compiling my original plugin project that was copied from the cinema4dsdk project from the R14.014 demo.

Edit:
Or does it really matter that the "stack_chk_guard" is showing up in the Terminal readout?

Adios,
Cactus Dan

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/09/2012 at 11:03, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy,[...] Is there some other setting that needs to change, that's causing the "stack_chk_guard"?
I'm still compiling my original plugin project that was copied from the cinema4dsdk project from the R14.014 demo.
Edit:
Or does it really matter that the "stack_chk_guard" is showing up in the Terminal readout?
Adios,
Cactus Dan

Honestly I'm not sure yet what can cause it. It's a little bit sus**cious as Rick's (messed up) project created the same symbol and it still contained the debug symbols, when looking at the file with a hex editor (even though nm didn't show it!).

I've created two new projects for Rick, one based on R13.061 SDK (which lets the plugin run in R13 & R14), the other one based on the R14.025 SDK and both were much shorter than his versions, didn't contain the debug symbols or the "stack_chk_guard" symbol - and both didn't crash anymore on OS X 10.8.1 with 14.025.

If you like, PM me and send me the project file and the compiled plugin dylib to have a look at.

Best regards,

Wilfried

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/09/2012 at 11:43, xxxxxxxx wrote:

Howdy,

I had Holger check a newly compiled plugin on Mountain Lion with the changed build settings, and that seemed to eliminate the crash, so I think I'm good to go to recompile the rest of them changing those settings.

Adios,
Cactus Dan

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/09/2012 at 22:38, xxxxxxxx wrote:

When I change Strip Style to "Non-Global Symbols", I get an error:

"Command /Developer_3.2.6./usr/bin/strip failed with exit code 1"

Not much info online so far about how to fix this. strip is definitely there. Must I also change the api_lib settings? Again, couldn't expect this to be simple. Something always screws me. You have screenshots of my configuration so let me know if something there is conflicting. Note that there are no other libs in use for the project causing the error (Solid Chamfer 2.1).

ETA: This is using the R12 SDK.

Thanks,

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/09/2012 at 23:14, xxxxxxxx wrote:

Here is the full transcript of the command:

trip ./SolidChamfer2.1.dylib  
cd /Users/roberttempleton/Documents/Cinema_4D_SDK/R12/plugins/SolidChamfer2.1  
/Developer_3.2.6/usr/bin/strip -x /Users/roberttempleton/Documents/Cinema_4D_SDK/R12/plugins/SolidChamfer2.1/./SolidChamfer2.1.dylib  
  
/Developer_3.2.6/usr/bin/strip: symbols referenced by indirect symbol table entries that can't be stripped in: /Users/roberttempleton/Documents/Cinema_4D_SDK/R12/plugins/SolidChamfer2.1/SolidChamfer2.1.dylib (for architecture x86_64)  
__ZNSt6vectorI21SC_ChangePolyVertexOpSaIS0_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS0_S2_EERKS0_  
__ZNSt6vectorI7LVectorSaIS0_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS0_S2_EERKS0_  
__ZNSt6vectorI8CPolygonSaIS0_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS0_S2_EERKS0_  
__ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi  
__ZNSt8_Rb_treeI7SC_EdgeS0_St9_IdentityIS0_ES0_SaIS0_EE13insert_uniqueERKS0_  
__ZNSt8_Rb_treeI7SC_EdgeS0_St9_IdentityIS0_ES0_SaIS0_EE7_M_copyEPKSt13_Rb_tree_nodeIS0_EPS6_  
__ZNSt8_Rb_treeI7SC_EdgeS0_St9_IdentityIS0_ES0_SaIS0_EE8_M_eraseEPSt13_Rb_tree_nodeIS0_E  
__ZNSt8_Rb_treeI7SC_EdgeS0_St9_IdentityIS0_ES0_SaIS0_EE9_M_insertEPSt18_Rb_tree_node_baseS6_RKS0_  
__ZNSt8_Rb_treeI7SC_EdgeSt4pairIKS0_11SC_EdgedataESt10_Select1stIS4_ES0_SaIS4_EE13insert_uniqueERKS4_  
__ZNSt8_Rb_treeI7SC_EdgeSt4pairIKS0_11SC_EdgedataESt10_Select1stIS4_ES0_SaIS4_EE13insert_uniqueESt17_Rb_tree_iteratorIS4_ERKS4_  
__ZNSt8_Rb_treeI7SC_EdgeSt4pairIKS0_11SC_EdgedataESt10_Select1stIS4_ES0_SaIS4_EE8_M_eraseEPSt13_Rb_tree_nodeIS4_E  
__ZNSt8_Rb_treeI7SC_EdgeSt4pairIKS0_11SC_EdgedataESt10_Select1stIS4_ES0_SaIS4_EE9_M_insertEPSt18_Rb_tree_node_baseSA_RKS4_  
__ZNSt8_Rb_treeI7SC_EdgeSt4pairIKS0_iESt10_Select1stIS3_ES0_SaIS3_EE13insert_uniqueERKS3_  
__ZNSt8_Rb_treeI7SC_EdgeSt4pairIKS0_iESt10_Select1stIS3_ES0_SaIS3_EE13insert_uniqueESt17_Rb_tree_iteratorIS3_ERKS3_  
__ZNSt8_Rb_treeI7SC_EdgeSt4pairIKS0_iESt10_Select1stIS3_ES0_SaIS3_EE8_M_eraseEPSt13_Rb_tree_nodeIS3_E  
__ZNSt8_Rb_treeI7SC_EdgeSt4pairIKS0_iESt10_Select1stIS3_ES0_SaIS3_EE9_M_insertEPSt18_Rb_tree_node_baseS9_RKS3_  
__ZNSt8_Rb_treeIiSt4pairIKi11SC_FacedataESt10_Select1stIS3_ESt4lessIiESaIS3_EE13insert_uniqueERKS3_  
__ZNSt8_Rb_treeIiSt4pairIKi11SC_FacedataESt10_Select1stIS3_ESt4lessIiESaIS3_EE13insert_uniqueESt17_Rb_tree_iteratorIS3_ERKS3_  
__ZNSt8_Rb_treeIiSt4pairIKi11SC_FacedataESt10_Select1stIS3_ESt4lessIiESaIS3_EE8_M_eraseEPSt13_Rb_tree_nodeIS3_E  
__ZNSt8_Rb_treeIiSt4pairIKi11SC_FacedataESt10_Select1stIS3_ESt4lessIiESaIS3_EE9_M_insertEPSt18_Rb_tree_node_baseSB_RKS3_  
__ZNSt8_Rb_treeIiSt4pairIKi13SC_VertexdataESt10_Select1stIS3_ESt4lessIiESaIS3_EE13insert_uniqueERKS3_  
__ZNSt8_Rb_treeIiSt4pairIKi13SC_VertexdataESt10_Select1stIS3_ESt4lessIiESaIS3_EE13insert_uniqueESt17_Rb_tree_iteratorIS3_ERKS3_  
__ZNSt8_Rb_treeIiSt4pairIKi13SC_VertexdataESt10_Select1stIS3_ESt4lessIiESaIS3_EE8_M_eraseEPSt13_Rb_tree_nodeIS3_E  
__ZNSt8_Rb_treeIiSt4pairIKi13SC_VertexdataESt10_Select1stIS3_ESt4lessIiESaIS3_EE9_M_insertEPSt18_Rb_tree_node_baseSB_RKS3_  
__ZNSt8_Rb_treeIiSt4pairIKi17VectorAccumulatorESt10_Select1stIS3_ESt4lessIiESaIS3_EE13insert_uniqueERKS3_  
__ZNSt8_Rb_treeIiSt4pairIKi17VectorAccumulatorESt10_Select1stIS3_ESt4lessIiESaIS3_EE13insert_uniqueESt17_Rb_tree_iteratorIS3_ERKS3_  
__ZNSt8_Rb_treeIiSt4pairIKi17VectorAccumulatorESt10_Select1stIS3_ESt4lessIiESaIS3_EE8_M_eraseEPSt13_Rb_tree_nodeIS3_E  
__ZNSt8_Rb_treeIiSt4pairIKi17VectorAccumulatorESt10_Select1stIS3_ESt4lessIiESaIS3_EE9_M_insertEPSt18_Rb_tree_node_baseSB_RKS3_  
__ZNSt8_Rb_treeIiSt4pairIKi9SC_OffsetESt10_Select1stIS3_ESt4lessIiESaIS3_EE13insert_uniqueERKS3_  
__ZNSt8_Rb_treeIiSt4pairIKi9SC_OffsetESt10_Select1stIS3_ESt4lessIiESaIS3_EE13insert_uniqueESt17_Rb_tree_iteratorIS3_ERKS3_  
__ZNSt8_Rb_treeIiSt4pairIKi9SC_OffsetESt10_Select1stIS3_ESt4lessIiESaIS3_EE7_M_copyEPKSt13_Rb_tree_nodeIS3_EPSB_  
__ZNSt8_Rb_treeIiSt4pairIKi9SC_OffsetESt10_Select1stIS3_ESt4lessIiESaIS3_EE8_M_eraseEPSt13_Rb_tree_nodeIS3_E  
__ZNSt8_Rb_treeIiSt4pairIKidESt10_Select1stIS2_ESt4lessIiESaIS2_EE13insert_uniqueERKS2_  
__ZNSt8_Rb_treeIiSt4pairIKidESt10_Select1stIS2_ESt4lessIiESaIS2_EE13insert_uniqueESt17_Rb_tree_iteratorIS2_ERKS2_  
__ZNSt8_Rb_treeIiSt4pairIKidESt10_Select1stIS2_ESt4lessIiESaIS2_EE7_M_copyEPKSt13_Rb_tree_nodeIS2_EPSA_  
__ZNSt8_Rb_treeIiSt4pairIKidESt10_Select1stIS2_ESt4lessIiESaIS2_EE8_M_eraseEPSt13_Rb_tree_nodeIS2_E  
__ZNSt8_Rb_treeIiSt4pairIKiiESt10_Select1stIS2_ESt4lessIiESaIS2_EE13insert_uniqueERKS2_  
__ZNSt8_Rb_treeIiSt4pairIKiiESt10_Select1stIS2_ESt4lessIiESaIS2_EE13insert_uniqueESt17_Rb_tree_iteratorIS2_ERKS2_  
__ZNSt8_Rb_treeIiSt4pairIKiiESt10_Select1stIS2_ESt4lessIiESaIS2_EE8_M_eraseEPSt13_Rb_tree_nodeIS2_E  
__ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE13insert_uniqueERKi  
__ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE7_M_copyEPKSt13_Rb_tree_nodeIiEPS7_  
__ZNSt8_Rb_treeIiiSt9_IdentityIiESt4lessIiESaIiEE8_M_eraseEPSt13_Rb_tree_nodeIiE  
__ZntRK7LMatrix  
__ZplRK6StringS1_  
Command /Developer_3.2.6/usr/bin/strip failed with exit code 1

And I get this for the default cinema4dsdk project Release:

  
Build cinema4dsdk of project cinema4dsdk with configuration Release  
  
Strip ./cinema4dsdk.dylib  
cd /Users/roberttempleton/Documents/Cinema_4D_SDK/R12/plugins/cinema4dsdk  
/Developer_3.2.6/usr/bin/strip -x /Users/roberttempleton/Documents/Cinema_4D_SDK/R12/plugins/cinema4dsdk/./cinema4dsdk.dylib  
  
/Developer_3.2.6/usr/bin/strip: symbols referenced by relocation entries that can't be stripped in: /Users/roberttempleton/Documents/Cinema_4D_SDK/R12/plugins/cinema4dsdk/cinema4dsdk.dylib (for architecture x86_64)  
__ZTV17EdgeCutPointArray  
__Z13blend_patternIfEvP7BM_TILET_  
__Z13blend_patternIhEvP7BM_TILET_  
__Z13blend_patternItEvP7BM_TILET_  
__ZntRK7LMatrix  
__ZplRK6StringS1_  
Command /Developer_3.2.6/usr/bin/strip failed with exit code 1

What the heck!?

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/09/2012 at 00:12, xxxxxxxx wrote:

This is very frustrating. Even using the R13 project for SolidChamfer has the same results. The dylib is created but no stripping occurs due to the error. How do I rectify this?

I have read the options for strip and '-r' does not help. Relocation and indirect symbol table entries are kicking my arse and I have no idea how to fix this.

Help - user complaints are mounting and I am getting pissed very quickly. I have two days before a 6-day work week to get this done (or they wait another week or more). Hurts my sales, my business, my reputation, everything. And, contrary to remarks at CGTalk, this is Apple's fault in the end. Can't blame Maxon, can't ever blame plugin developers.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/09/2012 at 00:34, xxxxxxxx wrote:

Update: the R13 cinema4dsdk builds properly. So I am going to copy it to all of my projects and redo them using it - though I'm pretty sure that I did this for any plugins built against R13. This might be something that changed from Xcode 3.2.1 to 3.2.6 that wasn't an issue or maybe an update in R13 that included the cinema4dsdk project? So, wish me luck in this - though it will mean updating some code for R13 for R12 latest-builds.

Thanks for bearing with my frustration!

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/09/2012 at 01:36, xxxxxxxx wrote:

Originally posted by xxxxxxxx

This is very frustrating. Even using the R13 project for SolidChamfer has the same results. The dylib is created but no stripping occurs due to the error. How do I rectify this?I have read the options for strip and '-r' does not help. Relocation and indirect symbol table entries are kicking my arse and I have no idea how to fix this.Help - user complaints are mounting and I am getting pissed very quickly. I have two days before a 6-day work week to get this done (or they wait another week or more). Hurts my sales, my business, my reputation, everything. And, contrary to remarks at CGTalk, this is Apple's fault in the end. Can't blame Maxon, can't ever blame plugin developers.

Hi Robert, I updated my initial post to the latest findings. The problem you observed is created by Apple removing support for global stripping from the final linked product in XCode 3.2 - if you use the R12 SDK you don't even get a warning about this problem, just a remark in the compiler log.

We just found out about that yesterday when debugging the build process of Frank's plugin with the R12 SDK and XCode 3.2.6 ...

Best regards,

Wilfried

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/09/2012 at 12:22, xxxxxxxx wrote:

Thanks for the information, Wilfried.

Builds with the R13 SDK and XCode 3.2.6 are now moving along and hope to get all of the plugins updated today.

Take care,

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2012 at 09:49, xxxxxxxx wrote:

Edit:
Sorry didn't mean to hijack anything.
Dan

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2012 at 11:14, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Hi. I've been trying to get Xcode working with Cinema, I;ve got 3.2.6 running on my Mac right now and the R13 SDK examples refuse to build but the R13 Demo SDK examples build without a problem on the first try. I've been reading through a lot of posts about getting Xcode to work, but I didn't see anything about the demo version working when the actual release one won't. Could it still be my Xcode having the incorrect settings or would my R13 SDK examples be wrong? Dan

Please don't hi-jack other threads; stay at the thread you've opened with your question and make that one as descriptive as possible.

Best regards,

Wilfried

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/10/2012 at 20:36, xxxxxxxx wrote:

I made the changes to my projects but kept getting the strip failure error that Robert was getting. I don't use any functionality of R13/R14, so the latest builds of my plugins are R12... so a lot of the info in these instructions don't apply to my current plugins. It didn't matter if I used xcode 3.1.4 or 3.2.6, the error popped up and symbol stripping didn't occur (though, ironically, I sent one of these builds to someone who was having trouble with one of my plugins and their response was "hey, working perfectly, thanks!" and I haven't heard anything to the contrary from them and they're actively using it on a project).

I started messing with some other symbol related project settings out of frustration and got a "strange" error about not being able to use both unexport and export lists. So this is what I did to get a successfully stripped R12 build (out of both 3.1.4 and 3.2.6) :

Uncheck "Separately Edit Symbols"
Delete the path for "Unexported Symbols File"

I tested this using clean cinema4dsdk projects from both R12 and R13 (so those settings were changed from default).

-kvb

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 13/11/2012 at 01:34, xxxxxxxx wrote:

Hi,

does anyone know where I could find the SDK 13.061 recommended by Maxon to build plugins for C4D R14 without these symbol stripping problems ??

We can't update our plugins on MacOS for now because it crashes C4D at startup...

Any help would very appreciated.

I didn't find the SDK on http://beta.villa.maxon.net/, there is a post about an update for the SDK 13.061 but it does not contain any download link.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 13/11/2012 at 03:32, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Hi,
does anyone know where I could find the SDK 13.061 recommended by Maxon to build plugins for C4D R14 without these symbol stripping problems ??

We can't update our plugins on MacOS for now because it crashes C4D at startup...

Any help would very appreciated.

The SDK 13.061 is the SDK that comes with R13.061. Update your installed CINEMA R13 to this version.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 13/11/2012 at 03:32, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Originally posted by xxxxxxxx

Hi,
does anyone know where I could find the SDK 13.061 recommended by Maxon to build plugins for C4D R14 without these symbol stripping problems ??

We can't update our plugins on MacOS for now because it crashes C4D at startup...

Any help would very appreciated.

The SDK 13.061 is the SDK that comes with R13.061. Update your installed CINEMA R13 to this version.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 13/11/2012 at 08:45, xxxxxxxx wrote:

Thanks, but I have another question: what is the address of the update server? By default I have bugslife.maxon.de:80. Is it correct ?

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 13/11/2012 at 09:54, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Thanks, but I have another question: what is the address of the update server? By default I have bugslife.maxon.de:80. Is it correct ?

Please post your questions about Beta in the appropriate forum. All the information is here.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/12/2012 at 15:41, xxxxxxxx wrote:

Hi Wilfried,

Originally posted by xxxxxxxx

- Use XCode 3.1.x only if you want to create plugins for R12 and with the R12 SDK. Check the compiler/linker log for messages indicating that stripping doesn't work anymore and use "nm" to verify that new/delete isn't exported. Don't use XCode 3.2.x or newer to create plugins with the R12 SDK.

I got a system set up now that I downgraded to use XCode 3.1.4 so I can do as you indicated above. It's for compiling a plugin which doesn't need any SDK functionality above R12 and that way we have one binary distributable for R12-R14. Doing as you advised still doesn't seem to work, though. I used the R12.48 SDK and there are still new and delete operators getting exported.

Did this work for anyone else?

Best
Timm

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 13/12/2012 at 00:09, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Hi Wilfried,

Originally posted by xxxxxxxx

- Use XCode 3.1.x only if you want to create plugins for R12 and with the R12 SDK. Check the compiler/linker log for messages indicating that stripping doesn't work anymore and use "nm" to verify that new/delete isn't exported. Don't use XCode 3.2.x or newer to create plugins with the R12 SDK.

I got a system set up now that I downgraded to use XCode 3.1.4 so I can do as you indicated above. It's for compiling a plugin which doesn't need any SDK functionality above R12 and that way we have one binary distributable for R12-R14. Doing as you advised still doesn't seem to work, though. I used the R12.48 SDK and there are still new and delete operators getting exported.

Did this work for anyone else?

Best
Timm

Then it might have already been broken in XCode 3.1.4; can't say for sure, as I have neither the required OS nor this XCode version to check - you should check the build log for this message:

"[…] nmedit: removing global symbols from a final linked no longer supported. […]"

If it is there, the XCode version you're using was already broken.

What I can say for sure is: We used XCode 3.1 (3.1; not 3.1.2 or 3.1.3 or 3.1.4) to build R12 and checking the plugins/modules distributed with R12 shows, that symbol stripping was working there. If you can't get rid of the new/delete symbols, then DON'T use this plugin with R13 or R14 (instead build an extra version based on the 13.061 SDK that can be used with R13 & R14).

Best regards,

Wilfried

Helper

On 13/03/2013 at 07:38, xxxxxxxx wrote:

OK, I'm lost. I tried several combinations of Xcode and project files (even the projects that come with the c4dsdk project) and I consistently failed to compile a single dylib that did *not* export new and delete. Is there any Xcode Wizz here that is close to either Düsseldorf, Berlin or Munich and could have a (paid) day to spare to figure this out with me?