Board SDK runs differently than bitbake build

Board SDK runs differently than bitbake build

[Gary Thomas]

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
------------------------------------------------------------