Re: toolchain for c++ on coldfire

Hi Angelo,

On 29/04/16 17:28, angelo wrote:
> i have the 5.3.0 c and c++ toolchain up and running.
> Last issue i had was compiling errors building a separate
> applications in c++, related to usleep undefined.
>
> To have usleep included in the recent uClibc library, you need
>
> UCLIBC_SUSV3_LEGACY=y
> UCLIBC_SUSV3_LEGACY_MACROS=y
>
>
>
> Many thanks for this great script.
>
> Could compile full uClinux-dist but with a recent kernel 4.5 (> 3.5).
>
> Still a last issue,
> if i compile a c++ app with this 5.3.0 toolchain, and upload it to a
> mcf5307 system, (kernel built with older toolchain and system
> with older uClibc) i get a strange
> "ILL" console message after execution, and program exits.
>
> am i doing something wrong ?

If you compile the c++ app within the uclinux-dist do you get the same 
result?

Can you post the c++ app?
Or at least a simple test case that shows the problem?

Regards
Greg



> On 29/04/2016 07:22, Greg Ungerer wrote:
>> Hi Waldemar,
>>
>> On 29/04/16 05:10, Waldemar Brodkorb wrote:
>>> Hi Greg,
>>> Greg Ungerer wrote,
>>>
>>>> Hi Angelo,
>>>>
>>>> On 20/04/16 04:14, angelo wrote:
>>>>> infinite thanks.
>>>>>
>>>>> Do you maybe have also the
>>>>> gcc-5.3.0-fix-libgcc-build.patch ?
>>>> Yep, attached.
>>> Can you explain why this patch is required and why
>>> the atomic code failes to compile?
>> It is required because it fails to compile without it :-)
>> I don't know why it fails, I didn't dig any further into it.
>>
>>> Do you mind to add some notes/comments to
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833
>> I don't see I can add any value there. I googled and found
>> Larry's bug report and fix at this link. The above patch is
>> exactly Larry's solution from that thread.
>>
>>
>>> There is another workaround in your script:
>>>       find ${GCCLIB} -name libgcc.a -print | while read t
>>>          do
>>>                  ${TARGET}-ar dv "$t" _ctors.o
>>>          done
>>>
>>> What kind of pain this is causing?
>> I don't know. It was in that script before I started using it.
>> It hasn't caused any problems with it there so I have never
>> removed it.
>>
>>
>>> Both works fine for me and the second workaround
>>> is simpler than my old way via a extra gcc spec file
>>> and a gcc-wrapper script.
>> So when you are compiling a modern gcc for m68k-uclinux you
>> don't hit the problem compiling linux-atomic.c?
>>
>> Regards
>> Greg
>>
>>
>> _______________________________________________
>> uClinux-dev mailing list
>> [email protected]
>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> This message was resent [email protected]
>> To unsubscribe see:
>> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
>
>
> _______________________________________________
> uClinux-dev mailing list
> [email protected]
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by [email protected]
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev