Plugin compiles but doesn't load... best practice?

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

On 21/11/2009 at 09:44, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   11 
Platform:    Mac  ;  
Language(s) :     C++  ;

---------
Well, I extended an existing plugin with two new shaders, still compiles nicely, but doesn't load.

What's in your experience the best way to find our what went wrong?
What are good checkpoints to exclude certain common issues?

Wouldn't it make sense to document a process/best practice for that?

Thanks for any help

Again a bit frustrated...

Kabe

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

On 21/11/2009 at 09:57, xxxxxxxx wrote:

What compiler are you using ? MS Visual C++?

~Shawn

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

On 21/11/2009 at 10:59, xxxxxxxx wrote:

Thanks for asking. I'm on Mac, so I'm using XCode under SnowLeopard.

Kabe

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

On 21/11/2009 at 11:42, xxxxxxxx wrote:

Hi,

i had that too several times, for me it was mostly that sth went wrong when registering the plugin in the main.cpp

so I would go there and check what the register..() function returns.
if it returns false set a breakpoint and step through the lines to see where it funks up.

cheers,
Daniel

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

On 21/11/2009 at 14:10, xxxxxxxx wrote:

PluginStart() is not even called, first line there is a GePrint...

BTW: I also had registration issues in the past.
Meanwhile I tackled them with a recommended practice:

If any of the register functions fails, then write a line in the console saying which one.

Thinking about it... would it make sense to do something like this for the pluginMessage C4DPL_INIT_SYS?

What I would find an incredible useful bit of information: Collecting all the info at *one* place, how to circle down to the common issues.

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

On 22/11/2009 at 05:33, xxxxxxxx wrote:

Turned out that this was not related to the source, but to compiler settings (compiling R11 on SnowLeopard is a bit strange sometimes. This again raises the question: How to check if a dylib contains the right code?

Kabe

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

On 23/11/2009 at 02:47, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Turned out that this was not related to the source, but to compiler settings (compiling R11 on SnowLeopard is a bit strange sometimes. This again raises the question: How to check if a dylib contains the right code?

Kabe

If you want to find out which architectures are supported by a library your can use the nm tool for this (it should also work with a dylib).

Start up the terminal and type "nm -arch YourRequiredArchtecture YourLibrary". If the library contains the architecture you'll get a symbol listing (which might also be handy if you have link problems or want to know how something is exported). Otherwise you'll get the message that the library doesn't contain the specified architecture.

Example usage:

nm -arch i386 /whereever/check_library.a
nm -arch x86_64 /whereever/check_library.a
nm -arch ppc /whereever/check_library.a
nm -arch ppc64 /whereever/check_library.a

Regarding where to start debugging: If PluginStart isn't called, C4DPL_INIT_SYS is the point to look at (as it is called on init. of the resources).

Best regards,

Wilfried Behne