[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] [Re: Sourcery G++ Lite 2010.09-55 for Power GNU/Linux toolcha

From: Stuart Hughes
Subject: Re: [Ltib] [Re: Sourcery G++ Lite 2010.09-55 for Power GNU/Linux toolchain]
Date: Thu, 11 Aug 2011 08:45:15 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11

Hi Aaron,

Just to confirm, this same toolchain works on 64 bit Ubuntu 11.04 but fails on 64 bit Fedora 15?

If so, then it may be worth asking on the CodeSourcery forum if there are any known issues. If not, maybe you can break this out to a simple test case (with no ltib in the loop) and send it to them.

Regards, Stuart

On 10/08/11 22:02, Aaron Wegner wrote:
Hi Stuart.  I was able to do a clean installation of x86_64 Fedora release
15 on a separate machine as well as a clean installation of the LTIB and
it fails in the same way as on my first machine.  Since this is stock
Fedora 15, I know it's not something funny I had going in my other
environment.  Some of the things you asked me to check for are below.
Also, same as before, modifying the spoof_wrapper to change the compiler
flag -B to -Wl,-L allows me to link the helloworld package normally.
Pretty sure anyone trying to use this toolchian on FC15 will run into this
and not be able to link.  Haven't tried it yet with some of CodeSourcery's
other versions of their G++ Lite toolchain for Power Architecture, but I
think I have at least one other one available so I might see what that
says.  Maybe it's limited to their latest toolchain release.

address@hidden ~/ltib Wed Aug 10 16:48:56]
$ ls rootfs/{lib,usr/lib}/*
rootfs/lib/  rootfs/usr/lib/
address@hidden ~/ltib Wed Aug 10 16:49:19]
$ cat rootfs/usr/lib/
/* GNU ld script
    Use the shared library, but some functions are only in
    the static library, so try that secondarily.  */
GROUP ( /lib/ /usr/lib/libc_nonshared.a  AS_NEEDED ( /lib/
) )
address@hidden ~/ltib Wed Aug 10 16:49:32]
$ find rootfs -name '*.a'
address@hidden ~/ltib Wed Aug 10 16:50:43]
$ grep STATIC config/platform/dbu5000/
address@hidden ~/ltib Wed Aug 10 16:51:04]

Hi Aaron,

Thanks for the output, that helps.

Given that it works on a 64bit Ubuntu, then it's probably that there's
some issue with either the Fedora setup/environment  or with the way the
BSP got built/setup on that machine.

On the machine where it fails can you do a:

$ ./ltib -m clean

This will de-populate rootfs/*.  Also just to make sure can you "sudo rm
-rf rootfs/*" after.

Then can you do:

$ ./ltib -f

This will force re-build what you previously had.

If that still doesn't work, then it would need further investigation.
You need to make sure that there is a valid*) in to
rootfs/lib,{usr/lib} area. Also the rootfs/usr/lib/ (a text file)
has an influence over the search paths during linking.

One final thing, make sure the static .a files from the toolchain are
not installed (this is an option you set in LTIB but by default is off),
this could cause issues and is something to eliminate.

Regards, Stuart

On 26/07/11 21:01, Aaron Wegner wrote:
Hi Stuart.  The output of the helloworld build is attached.  I was able
test on an Ubuntu 64-bit system and the LTIB works fine with the same
toolchain, so this might be a non-issue, or at least limited to Fedora?
The toolchain is an RPM file downloaded from their site:

So, it's the same toolchain for 32 and 64 bit hosts.  On a 64 bit host I
believe you need the 32 bit glibc libraries to execute the core programs
of the toolchain.  I will try loading the latest from Fedora on another
bit system as soon as I can to see if it's somehow related to my
installation.  The Ubuntu I tested with was:

address@hidden:~/Downloads Tue Jul 26 15:44:52]
$ cat /etc/lsb-release
address@hidden:~/Downloads Tue Jul 26 15:45:03]
$ uname -a
Linux ubuntu 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC
x86_64 x86_64 x86_64 GNU/Linux
address@hidden:~/Downloads Tue Jul 26 15:45:10]
$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 20
model           : 1
model name      : AMD C-30 Processor

Hi Aaron,

Could you post the "gcc" -v output from the attempt to build

It may be worth asking on the gcc mailing list why there is a
in behaviour between 32 and 64 bit hosts.

      * Are you running exactly the same toolchain on both? (or is one
built for 64 bit and one for 32 bit?)

Regards, Stuart

Regards, Stuart

On 25/07/11 16:53, Aaron Wegner wrote:
Hi Stuart.  I added your debug line to the spoof_wrapper file and it
prints out "rootfs stating area: /home/aaron/ltib/rootfs" as expected.
The new toolchain is definitely not liking the -B flag for some
My attempt to build vim is below.  The helloworld package reports the
exact same error: it can't link executables.  Works fine in Fedora 32
just not in a 64 bit version.


address@hidden ~/ltib/rpm/BUILD/vim62 Mon Jul 25 11:31:36]
$ cat src/auto/config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:616: checking whether make sets ${MAKE}
configure:646: checking for gcc
configure:759: checking whether the C compiler (gcc  ) works
configure:775: gcc -o conftest    conftest.c  1>&5
rootfs stating area: /home/aaron/ltib/rootfs
skipping incompatible /lib/ when searching for /lib/
cannot find /lib/
cannot find /usr/lib/libc_nonshared.a
cannot find /lib/
collect2: ld returned 1 exit status
configure: failed program was:

#line 770 "configure"
#include "confdefs.h"



Editing /opt/ltib/usr/spoof/spoof_wrapper in the following way fixes
things and I am able to link.

#    @srch  = ('-B', "$ENV{DEV_IMAGE}/usr/lib//",
       @srch  = ("-Wl,-L$ENV{DEV_IMAGE}/usr/lib//", # fixes 64-bit

Don't know if anyone else has seen this with the LTIB and a 64-bit
GNU/Linux distro.

Thanks again,


Hi Aaron,

It's a while since I looked at this, but the -B switch, does pretty
the same thing are your direct version.  The odd looking trailing //
necessary as otherwise (much) older toolchains will fail (it's a bug
the toolchains).

Once possibility is that for some reason the environment variable:
DEV_IMAGE does not get set properly, which would explain accessing
/usr/lib.  Alternately maybe the the path is not found using -B.

Unfortunately I don't have time to look into this at the moment.
you try the following:

Put the code back as it was, but add:
        print "rootfs stating area: $ENV{DEV_IMAGE}\n";
near the top of the spoof_wrapper file.

If that looks okay, can you try building the helloworld test rpm with
added to the compiler line, along the lines of:

./ltib -p helloworld -m prep

Edit rpm/BUILD/helloworld-1.1/Makefile and change the line:

CFLAGS   = -Wall
CFLAGS   = -Wall -v

and then run:
./ltib -p helloworld 2>&1 | tee helloworld_log.txt

If you look at the file you may be able to see whether the right
are being found for the linking.

Regards, Stuart

On 14/07/11 22:50, Aaron Wegner wrote:
I downloaded the latest CodeSourcery G++ Lite toolchain from their
and popped it into the LPP.


This RPM works fine with my 32-bit Fedora 12 development
my I have:

CONFIG_TOOLCHAIN_CFLAGS="-msoft-float -mcpu=860"

However, when I try the same on my 64-bit Fedora 15 development
workstation I find that I'm not able to link.  It bails with linker
such as:

skipping incompatible /lib/ when searching for
cannot find /lib/
cannot find /usr/lib/libc_nonshared.a
cannot find /lib/
collect2: ld returned 1 exit status

I poked around a little and found that if I edit the gcc spoof
found in


and put in the following hack around line 46

#    @srch  = ('-B', "$ENV{DEV_IMAGE}/usr/lib//",
       @srch  = ("-Wl,-L/home/aaron/ltib/rootfs/usr/lib//",

that all my programs compile and link like normal.  Is this a
the toolchain?  Is there a workaround that is an easy fix, or is
more difficult issue?



LTIB home page:

Ltib mailing list

LTIB home page:

Ltib mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]