Hello All,
I was not able to get gcell to compile (trunk 8156). I had to add the
patch
included to get gcell to compile. Has anyone been able to get this to
compile without modification? Any other ideas on what I may be doing
wrong?
Without the patch I get the following error
make[3]: Entering directory /mnt/share/trunk/gcell/src/apps' <snip> ppu32-g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_all test_all.o -L/mnt/cell-root/lib -L/mnt/cell-root/usr/lib ../../../gcell/src/lib/.libs/libgcell-qa.so /mnt/share/trunk/gcell/src/lib/.libs/libgcell.so -Wl,--rpath -Wl,/mnt/share/cell-install/lib /opt/cell/toolchain/bin/ppu-ld: warning: libspe2.so.2, needed by /mnt/share/trunk/gcell/src/lib/.libs/libgcell.so, not found (try using -rpath or -rpath-link) ../../../gcell/src/lib/.libs/libgcell-qa.so: undefined reference tospe_in_mbox_write’
…/…/…/gcell/src/lib/.libs/libgcell-qa.so: undefined reference to
`spe_event_handler_create’
Index: gcell/src/apps/Makefile.am
— gcell/src/apps/Makefile.am (revision 8156)
+++ gcell/src/apps/Makefile.am (working copy)
@@ -39,9 +39,12 @@
test_all_SOURCES = test_all.cc
test_all_LDADD = $(GCELL_QA_LA) $(GCELL_LA)
+test_all_LDFLAGS = -rpath /mnt/cell-root/usr/lib/
benchmark_dma_SOURCES = benchmark_dma.cc
benchmark_dma_LDADD = spu/benchmark_procs $(GCELL_LA) $(MBLOCK_LA)
+benchmark_dma_LDFLAGS = -rpath /mnt/cell-root/usr/lib/
benchmark_nop_SOURCES = benchmark_nop.cc
benchmark_nop_LDADD = spu/benchmark_procs $(GCELL_LA) $(MBLOCK_LA)
+benchmark_nop_LDFLAGS = -rpath /mnt/cell-root/usr/lib/
~
On Thu, Apr 03, 2008 at 06:38:20PM -0400, Tim M. wrote:
../../../gcell/src/lib/.libs/libgcell-qa.so: undefined reference to
`spe_event_handler_create'
Tim,
What distribution and version are you running on the build machine?
FC7 or F8?
I’ll try to reproduce it on my end, though last time I checked it
worked.
I’m assuming you configured with:
./configure-cell-cross --prefix=/mnt/share/cell-install
Eric
On Thu, Apr 03, 2008 at 08:01:06PM -0400, Tim M. wrote:
wrong?
/opt/cell/toolchain/bin/ppu-ld: warning: libspe2.so.2, needed by
What distribution and version are you running on the build machine?
FC7 or F8?
I am using Ubuntu Gutsy on the build machine; I am breaking one of the
“shalls” from the cross compile guide. I had been able to compile the trunk
for some time targeting both FC7 and FC8 on the PS3 without problem. This
was the first time I tried the gcell part. Until you asked I forgot about
the FC7/8 requirement. If it is an easy fix to make this work with Debian
derived distributions that would be a bonus.
The FC7/8 requirement is mostly driven by the SDK. Sounds like you’ve
worked around that part OK.
I think the failure is a “feature” of the broken libtool on
Debian/Ubuntu. I don’t it’s specific to gcell, just that that is
where you’re seeing it.
I suspect that if you do a non cross compile of GNU Radio, but specify a
non-standard value for --prefix (e.g…, /mnt/share/x86-install) you’ll
get a similar error, only at some other place in the build.
See
http://gnuradio.org/trac/wiki/UbuntuInstall#BrokenlibtoolonDebianandUbuntu
I’ll try to reproduce it on my end, though last time I checked it worked.
I’m assuming you configured with:
./configure-cell-cross --prefix=/mnt/share/cell-install
Yes. It all works fine as long as I add the “rpath” stuff to the
Makefile.am in “gcell/src/apps”
OK.
Just for the record, there’s no chance in hell that I’ll accept a
patch that codes a -rpath into *_LDFLAGS 
On Thu, Apr 3, 2008 at 9:28 PM, Eric B. [email protected] wrote:
included to get gcell to compile. Has anyone been able to get this
.libs/test_all
…/…/…/gcell/src/lib/.libs/libgcell-qa.so: undefined reference to
“shalls” from the cross compile guide. I had been able to compile the
worked around that part OK.
See
http://gnuradio.org/trac/wiki/UbuntuInstall#BrokenlibtoolonDebianandUbuntu
It may be libtool but I am not sure it is the same problem that we saw
before. The gcell tree is the only place I see this. It is when
linking to
existing libraries on the PS3 “/mnt/cell-root/usr/lib” that the problem
shows up. By doing a configure disabling gcell the cross build
completes.
I don’t think the work around in the wiki
http://gnuradio.org/trac/wiki/UbuntuInstall#BrokenlibtoolonDebianandUbuntu
is applicable here. I didn’t think the cross compiler should care what
is
in ld.so.conf. Just for kicks I did add a line /mnt/cell-root/usr/lib
and
/mnt/share/cell-install/lib to ld.so.conf and ran ldconfig just to see
if it
would build; it did not. Adding the lines caused a bunch of link errors
against cppunit. This just illustrates how little I understand some of
the
finer details of the build process.
Yes. It all works fine as long as I add the “rpath” stuff to the
Makefile.am in “gcell/src/apps”
OK.
Just for the record, there’s no chance in hell that I’ll accept a
patch that codes a -rpath into *_LDFLAGS
I was not expecting you to apply it as a patch. I only sent it to
better illustrate what I was seeing and to provide a temporary work
around
for others.
On Fri, Apr 04, 2008 at 06:45:46AM -0400, Tim M. wrote:
non-standard value for --prefix (e.g…, /mnt/share/x86-install) you’ll
get a similar error, only at some other place in the build.
See
http://gnuradio.org/trac/wiki/UbuntuInstall#BrokenlibtoolonDebianandUbuntu
It may be libtool but I am not sure it is the same problem that we saw
before. The gcell tree is the only place I see this. It is when linking to
existing libraries on the PS3 “/mnt/cell-root/usr/lib” that the problem
shows up. By doing a configure disabling gcell the cross build completes.
OK.
I don’t think the work around in the wiki
http://gnuradio.org/trac/wiki/UbuntuInstall#BrokenlibtoolonDebianandUbuntu
is applicable here.
I concur. That’s a work-around for a broken libtool on a native build.
OK.
Just for the record, there’s no chance in hell that I’ll accept a
patch that codes a -rpath into *_LDFLAGS
I was not expecting you to apply it as a patch. I only sent it to
better illustrate what I was seeing and to provide a temporary work around
for others.
Thanks. Glad to have the info.
I have recently seen an issue with cross compilation under F8 on
x86_64 using libtool 1.5.24. Not exactly sure about the problem or
fix. Just wanted to add it to the mix.
Eric