[yocto] Board SDK runs differently than bitbake build
Gary Thomas
gary at mlbassoc.com
Thu Jul 18 07:44:33 PDT 2013
I'm trying to get a fairly large project to build/run using
OpenEmbedded and running into a number of problems. The project
is the Automated Maryland backup system, amanda, which is quite
extensive and uses a lot of C+perl code.
The biggest problem I have is that the result when compiled via
bitbake doesn't run properly on my board. To try and narrow down
the problem, I wanted to build the package directly on my hardware,
removing any cross-build issues that might exist. I imported the
same source tree as used in my bitbake build, including all patches,
etc, to my board and run 'configure' using the same options minus the
cross-build options (no build/host/target settings).
However, when I run 'make' it fails with an error like this:
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../config -I../common-src -I../common-src -I../amandad-src -I../amar-src -
I../xfer-src -I../perl/amglue -I../gnulib -I../ndmp-src -I/usr/lib/perl/5.14.2/CORE -I../device-src -I../server-src -I.
./client-src -I../recover-src -fno-strict-aliasing -D_GNU_SOURCE -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/i
nclude -DSWIG -g -O2 -fno-strict-aliasing -c Amanda/Xfer.c -fPIC -DPIC -o .libs/Xfer.o
/bin/sh ../libtool --tag=CC --mode=link gcc -DSWIG -g -O2 -fno-strict-aliasing -avoid-version -shared -o libXfer.
la -rpath /usr/lib/perl/5.14.2/auto/Amanda/Xfer Xfer.lo amglue/libamglue.la ../xfer-src/libamxfer.la -lcrypto -lm -Wl,
--export-dynamic -pthread -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lnsl -lresolv
libtool: link: gcc -shared -fPIC -DPIC .libs/libXfer.la.lnkscript -Wl,-rpath -Wl,/home/root/amanda-3.3.3/perl/amglue/
.libs -Wl,-rpath -Wl,/home/root/amanda-3.3.3/xfer-src/.libs -Wl,-rpath -Wl,/home/root/amanda-3.3.3/common-src/.libs -L/
home/root/amanda-3.3.3/xfer-src/.libs -L/home/root/amanda-3.3.3/common-src/.libs amglue/.libs/libamglue.so -L/usr/lib /
home/root/amanda-3.3.3/xfer-src/.libs/libamxfer.so ../xfer-src/.libs/libamxfer.so /home/root/amanda-3.3.3/common-src/.l
ibs/libamanda.so -lcrypto -lm /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libgobject-2.0.so /usr/lib/libffi.so /usr/lib/li
bgthread-2.0.so /usr/lib/libglib-2.0.so -lpthread -lrt -lnsl -lresolv -O2 -Wl,--export-dynamic -pthread -pthread -Wl
,-soname -Wl,libXfer.so -o .libs/libXfer.so
libtool: link: rm -f .libs/libXfer.la.lnkscript
/bin/sed: can't read =/usr/lib/libgthread-2.0.la: No such file or directory
libtool: link: `=/usr/lib/libgthread-2.0.la' is not a valid libtool archive
The interesting thing is that library/file *is* present. If I
simply rerun 'make', this step runs properly and it carries on,
only to fail again with a similar error in some other part of
the build. Eventually, the build completes after about 20 make/retry
cycles. When I run 'make install', a new set of errors occurs:
make[5]: Leaving directory `/home/root/amanda-3.3.3/common-src'
/bin/mkdir -p '/usr/lib'
/bin/sh ../libtool --mode=install /usr/bin/install -c libamanda.la '/usr/lib'
libtool: install: /usr/bin/install -c .libs/libamanda-3.3.3.so /usr/lib/libamanda-3.3.3.so
libtool: install: (cd /usr/lib && { ln -s -f libamanda-3.3.3.so libamanda.so || { rm -f libamanda.so && ln -s libamanda
-3.3.3.so libamanda.so; }; })
libtool: install: /usr/bin/install -c .libs/libamanda.lai /usr/lib/libamanda.la
/usr/bin/install: cannot stat `.libs/libamanda.lai': No such file or directory
Neither of these [class of] errors happen when I build using 'bitbake'.
Both environments are in total sync - I've built the package using
the same build tree where I built my system image + SDK - so I don't
understand why the difference in behaviour.
An even more interesting thing is that I've build amanda on my BeagleBoneBlack
running Angstrom (also OE-core based and only a tiny bit older than the current
Poky/Yocto tree I use). I still had the build issues as above, but the resulting
code actually runs. I used the exact same 'configure' setup, same sources, etc.
The differences may be with the tools:
Poky/Yocto Angstrom
perl 5.14.3 5.14.2
gcc 4.7.2 4.7.3
I've also tried this on vastly different architectures - ARM & PowerPC - with
the same failures.
Any ideas/help/comments?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
More information about the yocto
mailing list