XCode link errors etc. *sigh*

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

On 20/02/2007 at 06:59, xxxxxxxx wrote:

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

---------
Hi,

I have now set my xcodeprojects to the exact same settings as the C4d sdk. For R9.6 this works all fine. My project compiles and runs (but still slow, see the other XCode thread!).

When I try to build it with the R10 SDK however, I get errors. However, not in my code! All my code files compile fine. It just gives me errors when it tries to link the dylib products.

I cleaned all targets and dependencies. So it´s a clean build. The API dependency also compiles absolutely fine.
Please I need a solution to this.

Here is the error messages I get:
    _cd "/Entwicklung/Cinema 4D R10/plugins/DPIT"
    /usr/bin/g++-4.0 -o /Entwicklung/Compiles/10UB/Final/dpit_10UB.build/Release/dpit_10UB.build/Objects-normal/i386/dpit_10UB.dylib -L/Entwicklung/Compiles/10UB/Final/Release -L../../resource/_api_maxon -L../../resource/_api_lib -F/Entwicklung/Compiles/10UB/Final/Release -filelist /Entwicklung/Compiles/10UB/Final/dpit_10UB.build/Release/dpit_10UB.build/Objects-normal/i386/dpit_10UB.LinkFileList /Entwicklung/Compiles/10UB/Final/Release/lib_api_release.a -arch i386 -exported_symbols_list ../../resource/_api_lib/export.txt -prebind -Wl,-single_module -compatibility_version 1 -current_version 1 -install_name /dpit_10UB.dylib -Wl,-Y,1455 -dynamiclib -mmacosx-version-min=10.3 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
ld: warning prebinding disabled because of undefined symbols
ld: Undefined symbols:
__ZTI10GeUserArea
__ZTI10iCustomGui
__ZTI13CustomGuiData
__ZTI13GeModalDialog
__ZTI19CustomDataTypeClass
__ZTI11CommandData
__ZTI17TreeViewFunctions
__ZTI6Thread
__ZTI8GeDialog
__ZTI12MaterialData
__ZTI10ShaderData
__ZTI10ObjectData
__ZTI7TagData
__ZTI8ToolData
__ZTI9SubDialog
__ZTI19DescriptionToolData
__ZTI13PrefsDlg_Base
__ZTI20PrefsDialogHookClass
__ZTI11SNHookClass
/Entwicklung/Compiles/10UB/Final/dpit_10UB.build/Release/dpit_10UB.build/Objects-normal/i386/dpit_datatype_list.o reference to undefined __ZTI10GeUserArea
/Entwicklung/Compiles/10UB/Final/dpit_10UB.build/Release/dpit_10UB.build/Objects-normal/i386/dpit_datatype_list.o reference to undefined __ZTI10iCustomGui
/Entwicklung/Compiles/10UB/Final/dpit_10UB.build/Release/dpit_10UB.build/Objects-normal/i386/dpit_datatype_list.o reference to undefined __ZTI13CustomGuiData

[goes on for all of my .cpp source files...reference to undefined _XXX_any_api_class_used error]

/usr/bin/libtool: internal link edit command failed
     ld: Undefined symbols:
     __ZTI10GeUserArea
     __ZTI10iCustomGui
     __ZTI13CustomGuiData
     __ZTI13GeModalDialog
     __ZTI19CustomDataTypeClass
     __ZTI11CommandData
     __ZTI17TreeViewFunctions
     __ZTI6Thread
     __ZTI8GeDialog
     __ZTI12MaterialData
     __ZTI10ShaderData
     __ZTI10ObjectData
     __ZTI7TagData
     __ZTI8ToolData
     __ZTI9SubDialog
     __ZTI19DescriptionToolData
     __ZTI13PrefsDlg_Base
     __ZTI20PrefsDialogHookClass
     __ZTI11SNHookClass
     /Entwicklung/Compiles/10UB/Final/dpit_10UB.build/Release/dpit_10UB.build/Objects-normal/i386/dpit_datatype_list.o reference to undefined __ZTI10GeUserArea
     /Entwicklung/Compiles/10UB/Final/dpit_10UB.build/Release/dpit_10UB.build/Objects-normal/i386/dpit_datatype_list.o reference to undefined __ZTI10iCustomGui
     /Entwicklung/Compiles/10UB/Final/dpit_10UB.build/Release/dpit_10UB.build/Objects-normal/i386/dpit_datatype_list.o reference to undefined __ZTI13CustomGuiData

[...]

/usr/bin/libtool: internal link edit command failed_

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

On 20/02/2007 at 07:32, xxxxxxxx wrote:

More information. When I compile my project in debug mode it compiles just fine! So only when I have it set to Release I get these errors.

How stupid is that?

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

On 20/02/2007 at 07:54, xxxxxxxx wrote:

As mentioned in another thread some days ago, I have similar problems with xcode. In my case there are linker errors only. But I can't see any rule in it. In most cases I have to build a debug version first, then the release version. Sometimes both two times.

As far as I remember, you specify a build directory in the xcode app settings. So maybe there occur complications if you once compile a R9 version and afterwards a R10 version???

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

On 20/02/2007 at 08:10, xxxxxxxx wrote:

Hi,

thanks Klaus. Yes, I had these "first debug, then Release" problems too! I don´t know why they now disappeared but it seems to work directly now. But don´t ask me why! I have absolutely no idea why!

Concerning the build directory. I have 2 different directories for R9 and R10, so this cannot be the problem. I also already had a working compile with the R10 SDK, but now that I have the SDK settings set, it doesn´t work correctly anymore.

Any other idea?

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

On 20/02/2007 at 08:56, xxxxxxxx wrote:

That doesn't seem to matter (the two different directories). Whenever I switch between projects, it always wants to recompile the api lib (even though I point to a compiled lib and only use the api project for '$(inherited)' and such).

Anyone experience a similar linking problem with delete() and delete? This one is directly relatable as c4d_memory.cpp makes it clear that the variations of these not be defined in XCode. But I get undefined nonetheless and cannot link otherwise (using a separate file to define them, but I'll bet the behaviour is undetermined). In c4d_memory.h they are declared always. I'm half tempted to add the preprocessor directive from c4d_memory.cpp to c4d_memory.h to remove the declarations as well as that might solve the problem (?).

XCode - such fun...

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

On 20/02/2007 at 09:00, xxxxxxxx wrote:

Hi,

no linking probs here for delete. However, API libs are not recompiled here anylonger. Had that problem at the beginning too but it disappeared too. yes, XCode sucks!

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

On 20/02/2007 at 09:05, xxxxxxxx wrote:

It compiles, it compiles!! :-)) I had the "C++ Exceptions" handling option activated and that made the linker not working somehow. How stupid is that? or isn´t it stupid? I don´t care really as long as everything works as expected.

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

On 20/02/2007 at 09:19, xxxxxxxx wrote:

My problem is that I need the "C++ Exceptions" option enabled for third-party encryption code. Drats!

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

On 20/02/2007 at 09:31, xxxxxxxx wrote:

Do you have this problem too?

Undefined symbols:
__ZdlPviPKc
__ZdaPviPKc

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

On 20/02/2007 at 09:47, xxxxxxxx wrote:

@Kuro: Drats is the right expression for this!

@Remo: Nope, don´t got these. Do you get them? Looks strange.

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

On 20/02/2007 at 09:56, xxxxxxxx wrote:

Well this was probably problem with "C++ Exceptions" adn new, delete operators with one of my projects.
Will try to reproduce it now... but XCode is really slow.

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

On 20/02/2007 at 10:06, xxxxxxxx wrote:

Quote: Originally posted by Remotion on 20 February 2007
>
> * * *
>
> Do you have this problem too?
>
> Undefined symbols:
> __ZdlPviPKc
> __ZdaPviPKc
>
>
> * * *

Yes, these are the ones.

I agree that it's related to C++ Exceptions. Currently going through the third-party encryption code and *very carefully* removing dependency upon exceptions. Actually not difficult - but last thing I want is broken serial number code!

And a side benefit - without C++ Exceptions, the resulting lib is 75 % of the size with C++ Exceptions enabled!

Doing this on Windows first and then will do the same in XCode. Will reply back with results (favorably, one hopes!).

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

On 20/02/2007 at 10:30, xxxxxxxx wrote:

yes, XCode is really slow with compiling and execution it seems. I tried now every possible option and it´s still slow as hell.

Anybody of you encountered performance problems with their XCode compiles in comparison with an according Windows compile or is it just me having these problems?

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

On 20/02/2007 at 10:36, xxxxxxxx wrote:

Concerning the Exceptions activation, the information says that it will activate it automatically for C++ projects. So is it really necessary to activate it? Do you still get errors when deactivating? Do you encounter any problems then without it being activated?

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

On 20/02/2007 at 12:32, xxxxxxxx wrote:

Part of the problem with XCode being slow on compile is that it is creating TWO compiles and links and then combining the PPC and i386 libs into the final dylib. Twice the compiling for twice the frustration.

Remember to take that into account.

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

On 20/02/2007 at 12:33, xxxxxxxx wrote:

Only enable C++ Exceptions if you are using exceptions (throw, try/catch). If there you are not using exceptions, there is no reason to have this enabled.

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

On 20/02/2007 at 16:29, xxxxxxxx wrote:

I am using throw and try and catch calls but I don´t have C++ Exceptions enabled in XCode because the information says that it´s enabled automatically for C++ code. So, is it really necessary to activate it manually when the compiler does anyway?

I am just saying that you get errors when activating it. But if you deactivate it you would get an error free compiling behavior and the option would still be activated automatically. That would be the solution to your initial problem if I understood correctly that you get errors on activating this option.

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

On 20/02/2007 at 18:45, xxxxxxxx wrote:

Possibly the compiler 'catches' the exception calls and then automatically enables exception handling. I hope that it doesn't assume exceptions when there are none.

Either way, disabling "Enable C++ Exceptions" removes the problems with delete() and delete and makes a clean compile.

Now hopefully we can all get our plugins compiled/linked without this b.s..

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

On 20/02/2007 at 18:47, xxxxxxxx wrote:

I do hope so too (but still have that sh*tty speed problem to solve).

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

On 21/02/2007 at 09:25, xxxxxxxx wrote:

Well fist "C++ Exceptions" not only make code larger but also slower some times.
try and catch still work without it, so it seems to be better to disable it.

For VC one can add
#pragma warning(disable: 4530)
to disable this warnings
warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc

@Samir: do you still have problems with speed?
I have also done some speed comparisons of my Windows with Core 2 Duo and slower Mac wrin Core Duo and get in mos case only 2 times slower execution.,

One time with really big test array the speed was 10X slower on Mac compared with Windows system....