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
_______________________________________________
LTIB home page: http://ltib.org
Ltib mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/ltib