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


Log in to reply