This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCSTUDIO-SITARA: CCS 10 GNU 9.2.1 Fails

Part Number: CCSTUDIO-SITARA
Other Parts Discussed in Thread: SYSBIOS

Hello,

Yet ANOTHER out of the box failure.

I have a project, It's an AM335x Project. Compiles with GNU 7.3  (linaro)

I go to the App Center page.

I install/update GNU 9.2.1 (Linaro)  (seen here after the fact)

Then try to build...   Right out of the box.  Problems with ITS OWN HEADERS.

+11  -fno-threadsafe-statics @"configPkg/compiler.opt"  -o"print.o" "../print.cpp"
subdir_rules.mk:30: recipe for target 'print.o' failed
cc1plus.exe: warning: switch '-mcpu=cortex-a8' conflicts with '-march=armv7-a' switch
In file included from c:\ti\bios_6_76_03_01\packages\gnu\targets\arm\libs\install-native\arm-none-eabi\include\stdio.h:60,
                 from ../print.cpp:1:
c:\ti\bios_6_76_03_01\packages\gnu\targets\arm\libs\install-native\arm-none-eabi\include\sys\reent.h:407:11: warning: unnecessary parentheses in declaration of '_sig_func' [-Wparentheses]
  407 |   void (**(_sig_func))(int);
      |           ^
In file included from c:\ti\ccs1011\ccs\tools\compiler\gcc-arm-none-eabi-9-2019-q4-major\arm-none-eabi\include\c++\9.2.1\cstdlib:75,
                 from c:\ti\ccs1011\ccs\tools\compiler\gcc-arm-none-eabi-9-2019-q4-major\arm-none-eabi\include\c++\9.2.1\bits\stl_algo.h:59,
                 from c:\ti\ccs1011\ccs\tools\compiler\gcc-arm-none-eabi-9-2019-q4-major\arm-none-eabi\include\c++\9.2.1\algorithm:62,
                 from ../print.cpp:4:
c:\ti\ccs1011\ccs\tools\compiler\gcc-arm-none-eabi-9-2019-q4-major\arm-none-eabi\include\stdlib.h:91:7: error: expected initializer before '__alloc_size2'
   91 |       __alloc_size2(1, 2) _NOTHROW;
      |       ^~~~~~~~~~~~~
In file included from c:\ti\ccs1011\ccs\tools\compiler\gcc-arm-none-eabi-9-2019-q4-major\arm-none-eabi\include\c++\9.2.1\bits\stl_algo.h:59,
                 from c:\ti\ccs1011\ccs\tools\compiler\gcc-arm-none-eabi-9-2019-q4-major\arm-none-eabi\include\c++\9.2.1\algorithm:62,
                 from ../print.cpp:4:
c:\ti\ccs1011\ccs\tools\compiler\gcc-arm-none-eabi-9-2019-q4-major\arm-none-eabi\include\c++\9.2.1\cstdlib:144:11: error: '::calloc' has not been declared
  144 |   using ::calloc;
      |           ^~~~~~
gmake: *** [print.o] Error 1

Does no one test these things before releasing them to users?

  • So. I dig in...  It's even MORE broken that I thought...

    I create a completely wizard generated project that is just a SYSBIOS.

    An empty "main.c" source file DOES compile  (but it won't link... see later down the post). 

    However a CPP file with the following headers fails:

    #include <stdio.h>
    #include <algorithm>
    

    So, you cannot use stdio.h and algorithm...

    And try to use algorithm on it's own, and it craters even more.

    In file included from c:\ti\ccs1011\ccs\tools\compiler\gcc-arm-none-eabi-9-2019-q4-major\arm-none-eabi\include\stdlib.h:18,
                     from c:\ti\ccs1011\ccs\tools\compiler\gcc-arm-none-eabi-9-2019-q4-major\arm-none-eabi\include\c++\9.2.1\cstdlib:75,
                     from c:\ti\ccs1011\ccs\tools\compiler\gcc-arm-none-eabi-9-2019-q4-major\arm-none-eabi\include\c++\9.2.1\bits\stl_algo.h:59,
                     from c:\ti\ccs1011\ccs\tools\compiler\gcc-arm-none-eabi-9-2019-q4-major\arm-none-eabi\include\c++\9.2.1\algorithm:62,
                     from ../dummy.cpp:4:
    c:\ti\bios_6_76_03_01\packages\gnu\targets\arm\libs\install-native\arm-none-eabi\include\sys\reent.h:168:8: error: '_VOID' does not name a type
      168 | extern _VOID   _EXFUN(__sinit,(struct _reent *));
          |        ^~~~~
    c:\ti\bios_6_76_03_01\packages\gnu\targets\arm\libs\install-native\arm-none-eabi\include\sys\reent.h:195:3: error: '_PTR' does not name a type
      195 |   _PTR _cookie; /* cookie passed to io functions */
          |   ^~~~
    c:\ti\bios_6_76_03_01\packages\gnu\targets\arm\libs\install-native\arm-none-eabi\include\sys\reent.h:197:36: error: '_read' has not been declared
      197 |   _READ_WRITE_RETURN_TYPE _EXFNPTR(_read, (struct _reent *, _PTR,

    Now, to run salt into this wound...

    If I remove the algorithm header from the main.cpp it will compile. 

    But won't link. I get linker errors about VFP ...

    makefile:145: recipe for target 'NewGNU.out' failed
    c:/ti/ccs1011/ccs/tools/compiler/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: error: NewGNU.out uses VFP register arguments, c:/ti/ccs1011/ccs/tools/compiler/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1\libgcc.a(_udivmoddi4.o) does not

    I can find nothing about the Vector Floating Point libs, and what any of the compiler/linkers settings mean.

    -----------------------------------------------------------------------------------------------------------

    (By the way...   why  HALF WAY THROUGH COMPOSING THIS, suddenly I can't insert a code block??)

    -CSW

  • Hello,

    From my understanding, GNU 7.2.1 should be used with AM335x and SYS/BIOS 6.76 (and the Processor SDK). It is unlikely that it was validated with GNU 9.2.1. I will bring this thread to the attention of the device experts for further comment

    Thanks

    ki

  • Ki,

    The PDK 6.0..... ,  Which doesn't tell you what's in it, until you download the 3/4 of a GIG package and launch the installer, apparently has GNU 7 in it.   I guess that's how it got installed on my pc, it was NOT through CCS 10,1

    Although the TI page on CCS says it comes with GCC 9  

    (https://software-dl.ti.com/ccs/esd/documents/ccs_downloads.html)

    It's not on my machine...   So I installed it from the App Center (as I said).

    I'll be ready to go into a tirade at the next person I hear from that says "You're using old stuff, you need to be using the latest versions"

    (And I have another post about the defects in that compiler where it doesn't know what __UULONG__ is for C++, but it does for C...  although I found a hack to get around it, and posted it)