4.11 Branch BSP C++ Build Issues

[Daniel Gutson]

On Wed, Oct 21, 2015 at 6:02 PM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
>
> On 10/21/2015 3:52 PM, Daniel Gutson wrote:
>>
>> On Wed, Oct 21, 2015 at 3:41 PM, Joel Sherrill
>> <joel.sherrill at oarcorp.com> wrote:
>>>
>>> Hi
>>>
>>> lm32, moxie, and nios2 all have generic issues with C++ applications
>>> which indicate C++ is not really supported by gcc for these targets.
>>
>>
>> Could you please provide more information/details about the error and
>> messages?
>> What does "C++ is not really supported" mean? C++ is front-end plus
>> the STL, and since
>> the front-end is target agnostic, I'm assuming there is some issue with
>> the STL.
>
>
> Ok.. if you see how to fix these, I am happy to push more testing. :)
>
> ======================================================
> lm32 all bsps fail similar to this
> ======================================================
> lm32-rtems4.11-g++ -B../../../../../lm32_evr_gdbsim/lib/ -specs bsp_specs
> -qrtems -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration
> -Wstrict-prototypes -Wnested-externs       -o cxx_iostream.exe init.o
> `.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev' referenced in section
> `.rodata.cst4' of
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(eh_terminate.o):
> defined in discarded section
> `.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev[_ZN9__gnu_cxx7__mutexD5Ev]' of
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(eh_terminate.o)
> `.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev' referenced in section
> `.rodata.cst4' of
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(new_handler.o):
> defined in discarded section
> `.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev[_ZN9__gnu_cxx7__mutexD5Ev]' of
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(new_handler.o)
> collect2: error: ld returned 1 exit status
>
> Both linkcmds appear to have the right magic:
>
>   .gcc_except_table   : {
>     *(.gcc_except_table)
>     *(.gcc_except_table.*)
>   } > sdram
>   ======================================================
> Moxie
> ======================================================
>
> moxie-rtems4.11-g++ -B../../../../../moxiesim/lib/ -specs bsp_specs -qrtems
> -Os -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes
> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
> -Wl,--gc-sections     -o cxx_iostream.exe init.o
> init.o: In function `__static_initialization_and_destruction_0':
> /data/home/joel/rtems-4.11-work/tools/lib/gcc/moxie-rtems4.11/4.9.3/include/c++/iostream:74:
> undefined reference to `__dso_handle'
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/moxie-rtems4.11/4.9.3/libstdc++.a(locale_init.o):
> In function `get_locale_mutex':
> /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/moxie-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/moxie-rtems4.11/libstdc++-v3/src/c++98/../../../../../gcc-4.9.3/libstdc++-v3/src/c++98/locale_init.cc:36:
> undefined reference to `__dso_handle'
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/moxie-rtems4.11/4.9.3/libstdc++.a(eh_alloc.o):
> In function `__static_initialization_and_destruction_0':
> /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/moxie-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/moxie-rtems4.11/libstdc++-v3/libsupc++/../../../../gcc-4.9.3/libstdc++-v3/libsupc++/eh_alloc.cc:96:
> undefined reference to `__dso_handle'
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/moxie-rtems4.11/4.9.3/libstdc++.a(eh_globals.o):
> In function `__static_initialization_and_destruction_0':
>

Those two (lm32 and Moxie) have problems with exception handling and
the linker scripts.
NIOS2 seems that it wants to use atomics but are not implemented,
instead of using the pthreads layer. (Sebastian?)

We can fix all of them but unfortunately have no time :(
What about at least disabling EH? I suggest build a multilib without
exceptions handling support (-fno-exceptions which will apply to the
STL).


> ======================================================
> NIOS2
> ======================================================
>
> Missing needed atomic operations.
>
> nios2-rtems4.11-g++ -B../../../../../nios2_iss/lib/ -specs bsp_specs -qrtems
> -mno-hw-mul -mno-hw-div -O0 -g -Wall -Wmissing-prototypes
> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
> -mno-hw-mul -mno-hw-div   -o cxx_iostream.exe init.o
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/nios2-rtems4.11/4.9.3/libstdc++.a(ios_init.o):
> In function `__exchange_and_add_dispatch':
> /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/nios2-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/nios2-
>
>
>



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:    dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson