Link errors in R10 but not R9 (Xcode)

Helper

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

On 03/04/2010 at 17:29, xxxxxxxx wrote:

Howdy,

Originally posted by xxxxxxxx

...Does the R10 c4d sdk compile fine for you?...

Yes, the R10 sdk project compiles fine, and so do all my other plugins. To create a plugin project I always start from a copy of the sdk project and change the names, settings and source files according to Maxon's guidelines in the xcodemigration.pdf file.

First, I set the plugin project up in R9.5, starting from the R9.5 sdk project, added the external library files, compiled it and there were link errors. After adding the Core Foundation and Core Services frameworks to the project, it compiled fine.

So, then I tried it in R10 doing the same steps as I did with R9.5, starting from a copy of the R10 sdk project, adding the external library files and adding the 2 additional Core frameworks to the project. But, then I got those link errors.

Then I tried the same thing in R9.6, and everything was fine just like in R9.5.

The latest thing I tried was to start from a copy of my plugin project that worked in R9.5 and just updated (Touched) the api project that's in the plugin project, and the same errors appear as starting from a copy of the R10 sdk project.

So the plugin project settings in this last attempt are the same as the R9.5 settings (which worked) but the api project was updated to R10. The conclusion seems like it would be a build setting in the R10 api project that must be different than the R9.5 api project. I'll have to go through and compare them 1 by 1 and see what the differences are.

Originally posted by xxxxxxxx

Just a side note when you're compiling under OS X 10.6: to compile at least the R11.x SDK you need to choose OS X 10.5 in the build settings as the basic framework. Might be related to your issue...

Right, but that's for Xcode3.0. When compiling for R10 using Xcode2.5, the only Mac SDK available is 10.4, which works fine for the R10 sdk project and every other R10 plugin I've compiled. And the Mac 10.4 SDK also worked fine compiling the plugin in R9.5.

The next thing I'm going to try is setting up the plugin project in R11 with Xcode3.0 and see if those same link errors appear.

Adios,
Cactus Dan

Helper

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

On 03/04/2010 at 17:39, xxxxxxxx wrote:

Ah ok, I see. However, it is strange that the additions of yours affect the api built. The api is build before your project and the api is not dependent on the project. So adding the libs shouldn´t affect the api build though withuot the knowing the libs it´s hard to tell.

Another assumption could be a problem similar to the windows problem where windows header files must be included before c4d includes (or was it the other way round). Could this be the case also for you? Including files from the library after the c4d includes (or the other way round)? However this would deal with the project build actually not the api build, so...hmm.

Comparing the flags set in the build settings is surely worth a try in any case.

Curious to see where this goes.

Helper

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

On 04/04/2010 at 06:51, xxxxxxxx wrote:

Howdy,

Well, this has really got me stumped.

I stored a copy of the R10 api project for safe keeping, so I can make changes to the build settings to match the R9.5 api build settings and that didn't work. The api compiled fine but the plugin project still has those link errors.

Then I also tried setting up the plugin project on another machine running the R11 demo and using Xcode3.0 and the same link errors appear.

Adios,
Cactus Dan

Helper

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

On 04/04/2010 at 07:17, xxxxxxxx wrote:

Howdy,

Also,I just tried creating a standard C++ application project, added the external library and the same function calls to the external library I was using in my plugin, and everything compiled fine there.

So, the problem seems to be c4d api R10+ related.

Adios,
Cactus Dan

Helper

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

On 05/04/2010 at 08:56, xxxxxxxx wrote:

Howdy,

Well, I tried every framework in the list, and non of them seem to solve the link errors when added to the project.

The external library I'm trying to use is the Autodesk FBX SDK 2010.2 library. I need to add fbx import/export support for my plugins, because the c4d fbx import/export doesn't recognize my plugin's joint object and skin tag.

Maybe Maxon's developers have encountered this same problem with the built in fbx import/export, since it also seems to be a dylib (plugin)?

Adios,
Cactus Dan

Helper

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

On 05/04/2010 at 09:11, xxxxxxxx wrote:

I will be in the office tommorrow again and will try if I also get errors on my MAC with the R10 sdk and the fbx lib linked. I´ll let you know.

Helper

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

On 08/04/2010 at 09:57, xxxxxxxx wrote:

Howdy,

Any word on this issue? Matthias?

Adios,
Cactus Dan

Helper

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

On 08/04/2010 at 15:28, xxxxxxxx wrote:

Howdy,

OK, it seems I've made some progress.

There seems to be an issue with libiconv library between 64/32 bit. I'm able to compile in R10 but only for intel 32 bit (i386), and only on my 32bit core duo machine running Leopard.
if I open the terminal on that machine and type in:

file /opt/local/lib/libiconv.dylib

... it displays this:

/opt/local/lib/libiconv.dylib: Mach-O dynamically linked shared library i386

On my core 2 quad machine running Snow Leopard, the libiconv library is 64 bit only.
On this machine typing in the above line in the terminal displays this:

/opt/local/lib/libiconv.dylib: Mach-O 64-bit dynamically linked shared library x86_64

When I use that same terminal command with the path to the FBX SDK library file, it displays this:

/Xcode2.5/FBXSDK20102/lib/libfbxsdk_gcc4_ub.a: Mach-O universal binary with 4 architectures   
/Xcode2.5/FBXSDK20102/lib/libfbxsdk_gcc4_ub.a (for architecture ppc) : current ar archive   
/Xcode2.5/FBXSDK20102/lib/libfbxsdk_gcc4_ub.a (for architecture i386) : current ar archive   
/Xcode2.5/FBXSDK20102/lib/libfbxsdk_gcc4_ub.a (for architecture ppc64) : current ar archive   
/Xcode2.5/FBXSDK20102/lib/libfbxsdk_gcc4_ub.a (for architecture x86_64) : current ar archive

So the conclusion may be that the FBX SDK supports all architectures but the libiconv library only supports specific machines.

I'm not sure if there is a universal binary version of libiconv available.

Adios,
Cactus Dan

Helper

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

On 09/04/2010 at 07:16, xxxxxxxx wrote:

FYI I can confirm the issue and have contacted the developers.

I can build plugins linked against the FBX library for Cinema R10 without problems.

With Cinema R11 64bit I got some undefined symbols.

cheers,
Matthias

Helper

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

On 09/04/2010 at 07:53, xxxxxxxx wrote:

Originally posted by xxxxxxxx

[...]
So the conclusion may be that the FBX SDK supports all architectures but the libiconv library only supports specific machines.

I'm not sure if there is a universal binary version of libiconv available.

Adios,
Cactus Dan

The readme.txt of the PC version of the FBX SDK explicitly states, that they don't support ppc64. If memory serves me right we once tried to get around those problems (by faking some lib entry points) after discovering, that the SDK contained ppc64 bit code - but finally failed due to a missing method (inside of the FBX SDK).

Best regards,

Wilfried Behne

Helper

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

On 09/04/2010 at 07:59, xxxxxxxx wrote:

Howdy,

Thanks Matthias.

Something else I discovered:
When installing the libiconv port using MacPorts, if I add "+universal" to the command like this:

sudo port install libiconv +universal

... then it installs a universal binary version of libiconv

But, on my core 2 quad machine running Snow Leopard, it only installs it for i386 & x86_64.:

/opt/local/lib/libiconv.2.dylib: Mach-O universal binary with 2 architectures   
/opt/local/lib/libiconv.2.dylib (for architecture i386) : Mach-O dynamically linked shared library i386   
/opt/local/lib/libiconv.2.dylib (for architecture x86_64) : Mach-O 64-bit dynamically linked shared library x86_64

... and on my core duo machine running Leopard it only installs it for ppc & i386:

/opt/local/lib/libiconv.2.dylib: Mach-O universal binary with 2 architectures   
/opt/local/lib/libiconv.2.dylib (for architecture ppc7400) : Mach-O dynamically linked shared library ppc   
/opt/local/lib/libiconv.2.dylib (for architecture i386) : Mach-O dynamically linked shared library i386

What I really need is an install for ppc, i386, ppc64 & x86_64, but I haven't found a way to get that yet.

The reason I've installed it from MacPorts (even though the libiconv.2.dylib is in the MacOS sdks) is that to get my plugin to compile in R10 and above, I used the "libiconv.a" static library from the MacPorts installation, since I couldn't figure out the right framework to include or build setting in the project to get it to compile without the link errors.

Adios,
Cactus Dan

Helper

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

On 09/04/2010 at 08:04, xxxxxxxx wrote:

I remember we had a simlar issue with this lib a while ago in a completely unrelated project.

At that time the problem was that the libiconv from /usr/local/lib was used, which only contains just the current architecture. There was another one in a different folder which contained all architectures. I'm just traing to find the exact information on this, but maybe this hint could help you already.

Kabe

Helper

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

On 09/04/2010 at 08:12, xxxxxxxx wrote:

Howdy,

Originally posted by xxxxxxxx

...The readme.txt of the PC version of the FBX SDK explicitly states, that they don't support ppc64. If memory serves me right we once tried to get around those problems (by faking some lib entry points) after discovering, that the SDK contained ppc64 bit code - but finally failed due to a missing method (inside of the FBX SDK)...

Thanks for that bit of info, Wilfried.

Maybe that will be fixed in fbx 2011?

Adios,
Cactus Dan

Helper

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

On 09/04/2010 at 08:16, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy,

Originally posted by xxxxxxxx

...The readme.txt of the PC version of the FBX SDK explicitly states, that they don't support ppc64. If memory serves me right we once tried to get around those problems (by faking some lib entry points) after discovering, that the SDK contained ppc64 bit code - but finally failed due to a missing method (inside of the FBX SDK)...

Thanks for that bit of info, Wilfried.

Maybe that will be fixed in fbx 2011?

Adios,
Cactus Dan

Haven't looked into that version, but I wouldn't be suprised if they finally dropped PPC support completely.

Best regards,

Wilfried Behne

Helper

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

On 09/04/2010 at 08:26, xxxxxxxx wrote:

Howdy,

Originally posted by xxxxxxxx

...Haven't looked into that version, but I wouldn't be suprised if they finally dropped PPC support completely...

You're probably right.

Adios,
Cactus Dan