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

[Aaron Wegner]

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}/libc.so*
rootfs/lib/libc.so.6  rootfs/usr/lib/libc.so
address@hidden ~/ltib Wed Aug 10 16:49:19]
$ cat rootfs/usr/lib/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-powerpc)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( /lib/ld.so.1
) )
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/defconfig.dev
# CONFIG_PKG_LIBC_WANT_STATIC_LIBS is not set
# CONFIG_PKG_CXX_WANT_STATIC_LIBS is not set
CONFIG_DEPLOYMENT_RM_STATIC_LIBS=y
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 libc.so(*) in to
> rootfs/lib,{usr/lib} area. Also the rootfs/usr/lib/libc.so (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
>> to
>> 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:
>>
>> http://www.codesourcery.com/sgpp/lite/power/portal/subscription3132
>>
>> 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
>> 64
>> 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
>> DISTRIB_ID=Ubuntu
>> DISTRIB_RELEASE=11.04
>> DISTRIB_CODENAME=natty
>> DISTRIB_DESCRIPTION="Ubuntu 11.04"
>> 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
>> 2011
>> 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
>>> helloworld?
>>>
>>> It may be worth asking on the gcc mailing list why there is a
>>> difference
>>> 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
>>>> reason.
>>>> 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
>>>> bit,
>>>> 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
>>>> /opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/lib/gcc/powerpc-linux-gnu/4.5.1/../../../../powerpc-linux-gnu/bin/ld:
>>>> skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
>>>> /opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/lib/gcc/powerpc-linux-gnu/4.5.1/../../../../powerpc-linux-gnu/bin/ld:
>>>> cannot find /lib/libc.so.6
>>>> /opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/lib/gcc/powerpc-linux-gnu/4.5.1/../../../../powerpc-linux-gnu/bin/ld:
>>>> cannot find /usr/lib/libc_nonshared.a
>>>> /opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/lib/gcc/powerpc-linux-gnu/4.5.1/../../../../powerpc-linux-gnu/bin/ld:
>>>> cannot find /lib/ld.so.1
>>>> collect2: ld returned 1 exit status
>>>> configure: failed program was:
>>>>
>>>> #line 770 "configure"
>>>> #include "confdefs.h"
>>>>
>>>> main(){return(0);}
>>>>
>>>> ----
>>>>
>>>> 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
>>>> Fedora
>>>>
>>>> Don't know if anyone else has seen this with the LTIB and a 64-bit
>>>> GNU/Linux distro.
>>>>
>>>>
>>>> Thanks again,
>>>>
>>>> Aaron
>>>>
>>>>
>>>>> Hi Aaron,
>>>>>
>>>>> It's a while since I looked at this, but the -B switch, does pretty
>>>>> much
>>>>> the same thing are your direct version.  The odd looking trailing //
>>>>> is
>>>>> necessary as otherwise (much) older toolchains will fail (it's a bug
>>>>> in
>>>>> 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.
>>>>> Could
>>>>> 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
>>>>> -v
>>>>> 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
>>>>> to:
>>>>> 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
>>>>> paths
>>>>> 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
>>>>>> site
>>>>>> and popped it into the LPP.
>>>>>>
>>>>>> /opt/ltib/pkgs/freescale-powerpc-linux-gnu-2010.09-55.i686.rpm
>>>>>>
>>>>>> This RPM works fine with my 32-bit Fedora 12 development
>>>>>> workstation.
>>>>>> In
>>>>>> my defconfig.dev I have:
>>>>>>
>>>>>> CONFIG_TOOLCHAIN="freescale-powerpc-linux-gnu-2010.09-55.i686.rpm"
>>>>>> CONFIG_TOOLCHAIN_PATH="/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu"
>>>>>> CONFIG_TOOLCHAIN_PREFIX="powerpc-linux-gnu-"
>>>>>> 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
>>>>>> errors
>>>>>> such as:
>>>>>>
>>>>>> ----
>>>>>> /opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/lib/gcc/powerpc-linux-gnu/4.5.1/../../../../powerpc-linux-gnu/bin/ld:
>>>>>> skipping incompatible /lib/libc.so.6 when searching for
>>>>>> /lib/libc.so.6
>>>>>> /opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/lib/gcc/powerpc-linux-gnu/4.5.1/../../../../powerpc-linux-gnu/bin/ld:
>>>>>> cannot find /lib/libc.so.6
>>>>>> /opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/lib/gcc/powerpc-linux-gnu/4.5.1/../../../../powerpc-linux-gnu/bin/ld:
>>>>>> cannot find /usr/lib/libc_nonshared.a
>>>>>> /opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/lib/gcc/powerpc-linux-gnu/4.5.1/../../../../powerpc-linux-gnu/bin/ld:
>>>>>> cannot find /lib/ld.so.1
>>>>>> collect2: ld returned 1 exit status
>>>>>> ----
>>>>>>
>>>>>> I poked around a little and found that if I edit the gcc spoof
>>>>>> source
>>>>>> found in
>>>>>>
>>>>>> /opt/ltib/usr/spoof/gcc
>>>>>>
>>>>>> 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
>>>>>> product
>>>>>> of
>>>>>> the toolchain?  Is there a workaround that is an easy fix, or is
>>>>>> this
>>>>>> a
>>>>>> more difficult issue?
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Aaron
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> LTIB home page: http://ltib.org
>>>>>>
>>>>>> Ltib mailing list
>>>>>> address@hidden
>>>>>> https://lists.nongnu.org/mailman/listinfo/ltib
>>>>>>
>
>