Re: [uClinux-dev] toolchain for c++ on coldfire

2016-04-29 Thread angelo

  
  
Hi,
  
  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 ?
  
  Thanks, 
  regards,
  angelo

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
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev



  

___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] toolchain for c++ on coldfire

2016-04-29 Thread Waldemar Brodkorb
Hi Greg,
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.
 
I think it is still required. Without it, an image for
qemu-system-m68k does not boot completely.
 
> > 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?

I hit it. And I would like to get it resolved upstream.
Furthermore the buildroot people are very strict about submissions
and want to know all glory details about a required patch :)

So I just thought I might get some more detailed explanation from
the uClinux experts.

best regards
 Waldemar
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev