Re: ct-ng: CLooG link failure in canadian-cross context

[Bernhard Pfund <bernhard at chapter7 dot ch>]

Yann, All

Yann E. MORIN wrote:
> Bwrnhard, All,
>
> On Wednesday 28 July 2010 11:51:54 Bernhard Pfund wrote:
> > I'm trying to create a powerpc-e500v2-linux-uclibcspe toolchain for a Windows 
> > host, using the canadian build-mode from ct-ng (hg tree from July 26.). I've
> > successfully built the Linux host version and the additional i686-pc-mingw32
> > chain, but now I'm stuck with a CLooG linker failure in step 3. of Yann's 
> > 'recipe' for canadian builds:
> [--SNIP--]
> > For some reason the linker is looking for c++ interfaces in libppl_c.a, which is 
> > IMO obviously bound to go wrong. Anyone seen this behaviour before?
> > Any hints greatly appreciated!
>
> > [Canadian config powerpc-e500v2Can-linux-uclibcspe]
>
> I'll come back to that later, when I have time to look at it.
> I'm afraid it won't be before the WE, as I'm trying to get 1.8.0 out
> in time (saturday if I stick to the plan).

No problem ;)

> > P.S. I had to modify ct-ng to get the uclibcspe configuration to work in the 
> > first place, but I can't see any relation to the error I'm experiencing now.
>
> > [QUICK AND DIRTY HACKS]
> > --- gcc.sh_sav  2010-07-26 15:54:10.000000000 +0200
> > +++ gcc.sh      2010-07-26 15:55:54.000000000 +0200
> [--SNIP libmudflap--]
>
> Nice idea. I've turned that into a config knob: build libmudflap or not?

We could even take this a little bit further and make most of the runtime libs 
selectable: libgomp, libssp, libmudflap. libdecnumber I'd leave alone there. 
Would make sense IMHO...

> > --- powerpc.sh_sav      2010-07-28 11:49:09.000000000 +0200
> > +++ powerpc.sh  2010-07-26 14:35:20.000000000 +0200
> > @@ -10,6 +10,10 @@
> >       case "${CT_LIBC},${CT_ARCH_POWERPC_SPE}" in
> >           glibc,|eglibc,)   CT_TARGET_SYS=gnu;;
> >           glibc,y|eglibc,y) CT_TARGET_SYS=gnuspe;;
> > +        uClibc) CT_TARGET_SYS=uclibc;;
> > +        uClibc,y) CT_TARGET_SYS=uclibcspe;;
> > +        newlib) CT_TARGET_SYS=elf;;
> > +        newlib,y) CT_TARGET_SYS=elfspe;;
>
> Are you sure about the uclibcspe thing? If I refer to the ARM EABI case,
> the correct tuple ends in -uclibcgnueabi. And if we follow that for
> the PPC SPE case, then we'd get -uclibcgnuspe. As for elfspe, do we
> really expect people to run bare-metal on such a machine ?

Actually, that's exactly where I'm going (eventually)... ;)

> > [Config powerpc-e500v2-linux-uclibcspe]
>
> Oh, you did build that one successfully, didn't you? So it seems the
> uclibcspe stuff is correct, then. Hmmm. Debian is doing that as well:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575158

Yes I have, was a tricky one though! gcc-4.5.0 and 4.4.x were buggy for e500, or 
rs6000 respectively (http://gcc.gnu.org/bugzilla//show_bug.cgi?id=44067), so I 
moved forward to 4.5.1 (RC 20100722). GCC accepts linux-uclibc* | 
uclinux-uclibc* | uclinux-gnu*, so I tried.

> So OK. Let's queue that for after 1.8.0...

Sure...

Best::Bernhard


--
For unsubscribe information see http://sourceware.org/lists.html#faq