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 05:48, xxxxxxxx wrote:

Originally posted by xxxxxxxx

I think I followed your instructions correctly, but the plugin is still hanging in R14. I'm still using Xcode 3 - do I have to update to Xcode 4? Will the plugin still work in R12 if I compile in XCode 4 using the R14 sdk project?

[...]

Follow-up FYI. Turns out a few things went wrong (mixed-up project & target settings in Xcode 3). Although your target settings modified the stripping (should have happened in the project settings) and nm did report just a few symbols, the size of your dylib (680 kb) was sus**cious - and there had been a few symbols used that are related to debugging (e.g. the stack_chk_guard symbol).

Dragging the dylib on a hexeditor shows, that the symbols & debug symbols are still there. Might be caused by the mixed-up project/target settings or by XCode 3.2 - we discovered today that removing global symbol from a final linked dylib based on the r12 sdk didn't work anymore in XCode 3.2.6 (while it did with XCode 3.1 that we used for building r12). Xcode doesn't even warn you about that; you've to look into the log output to discover it. More on that later - we're preparing a document about it...

I've set up your plugin project based on the r13 sdk and the size shrinked down to 111 kb, symbols are stripped and the crash on 10.8.1 is gone.

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 07:26, xxxxxxxx wrote:

Howdy,

I noticed that my plugin CD Symmetry Tools is in the list of plugins causing a crash, but the deployment settings in my plugin's project show that I am using the "Non-Global Symbols" setting in the release version:

Since I don't really know much about the specific project settings, I simply copied the cinema4dsdk project, deleted the source, added my own source code and then changed the Product Name to my plugin's name.

Do I need to change something else?

Adios,
Cactus Dan
P.S. My plugins were compiled with the first R14.014 demo on a 32bit machine running Snow Leopard 10.6.8 and Xcode 4.2

Helper

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

On 11/09/2012 at 07:50, xxxxxxxx wrote:

Hi Dan,

This is confusing me, too. Because you've got Strip Style set to non-global symbols for release, so they should be stripped, but under strip linked product for release it says 'no'. Does that mean the symbols are being stripped or not? Beats me, I sure don't know.

And it's worrying because I also used the sdk project as the basis for the compile on R14 (though it is the 14.025 version if that makes any difference).

Steve

Helper

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

On 11/09/2012 at 07:58, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy,
I noticed that my plugin CD Symmetry Tools is in the list of plugins causing a crash, but the deployment settings in my plugin's project show that I am using the "Non-Global Symbols" setting in the release version:

Since I don't really know much about the specific project settings, I simply copied the cinema4dsdk project, deleted the source, added my own source code and then changed the Product Name to my plugin's name.
Do I need to change something else?
Adios,
Cactus Dan
P.S. My plugins were compiled with the first R14.014 demo on a 32bit machine running Snow Leopard 10.6.8 and Xcode 4.2

For the release build make sure stripping is enabled ("strip linked product -> Release: Yes"). Please check project and target settings for that.

Use the "nm <path> | c++filt -p -i" command to verify that new & delete symbols aren't exported.

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 08:02, xxxxxxxx wrote:

Howdy,

OK, I've just discovered something. Since I have several machines and always prefer to install updates on a separate machine first, I have the first R14.014 demo, the release version R14.014 and the updated R14.025 demo available and there are different settings for the "Strip Linked Product" parameter in the cinema4dsdk project:
R14.014 demo:
Debug = Yes
Release = No

R14.014 release:
Debug = No
Release = No

R14.025 demo:
Debug = Yes
Release = Yes

So, maybe the latest settings are correct?

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 08:08, xxxxxxxx wrote:

Howdy,

Originally posted by xxxxxxxx

...For the release build make sure stripping is enabled ("strip linked product -> Release: Yes"). Please check project and target settings for that....

AHA! So my assumption was correct that the latest version's settings are the ones to use. Thanks.

Edit:
Or should the Debug be set to No?

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 08:17, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy,

Originally posted by xxxxxxxx

...For the release build make sure stripping is enabled ("strip linked product -> Release: Yes"). Please check project and target settings for that....

AHA! So my assumption was correct that the latest version's settings are the ones to use. Thanks.
Edit:
Or should the Debug be set to No?
Adios,
Cactus Dan

You can change that, but I think the target settings for debug already do that (for you).

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 08:38, xxxxxxxx wrote:

Howdy,

Originally posted by xxxxxxxx

...Use the "nm <path> | c++filt -p -i" command to verify that new & delete symbols aren't exported...

When I use that, it gives me an error:

-bash: nm: command not found

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 08:52, xxxxxxxx wrote:

Howdy,

DOH! disregard that previous post. I was trying that through the network from a different machine. When I did that on the machine where I did the compile, it gave me this readout:

                 U std::nothrow
                 U ___bzero
                 U ___cxa_atexit
                 U ___stack_chk_fail
                 U ___stack_chk_guard
                 U _asin
00000000000340e0 T _c4d_main
                 U _cos
                 U _free
                 U _malloc
                 U _memcpy
                 U _memset
                 U dyld_stub_binder

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 08:56, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy, DOH! disregard that previous post. I was trying that through the network from a different machine. When I did that on the machine where I did the compile, it gave me this [...]

Was that a debug build, or have you manually changed some settings or do you use some external libs? The "stack_chk_guard" isn't supposed to be in a release build, at least not in our usual builds.

nm needs installed devtools on the machine to work.

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 09:13, xxxxxxxx wrote:

Howdy,

Well, crap! Now I'm not sure where to set whether it's a Release or Debug build (I'm somewhat lost in Xcode 4).

This was the only place where I could find a choice between Debug and Release:

Is that only for the command line build?

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 09:40, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy,
Well, crap! Now I'm not sure where to set whether it's a Release or Debug build (I'm somewhat lost in Xcode 4).
This was the only place where I could find a choice between Debug and Release:

Is that only for the command line build?
Adios,
Cactus Dan

There is a XCode 4 transition guide @Apple: http://developer.apple.com/library/mac/#/legacy/mac/library/documentation/IDEs/Conceptual/Xcode4TransitionGuide/Introduction/Introduction.html

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

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 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