Re: Segmentation fault

[Anthony Foiani <anthony dot foiani at gmail dot com>]

Michael --

On Tue, Mar 5, 2013 at 8:30 PM, Michael Powell <mwpowellhtx@gmail.com> wrote:
> I have an idea what 'ldd' is. Check that the libraries are there on
> one or both systems.

Right, although you'll generally want to use the 'ldd' that is built
with the correct host and target.

That is, the /usr/bin/ldd on your native linux host will be built to
run on, and to parse, binaries for the host (linux x86).

(There is some wriggle room, as many of the binutils are capable of
dealing with binaries on alien systems.)

If you want to see what dependencies your cross-compiled binaries
have, however, you want to use the ldd that is built as a part of the
cross-compile toolchain.  (This means that "host" is "linux x86",
while "target" is "arm".)  This should be in the same directory as the
cross-compiling gcc, something like:

/..../x-tools/bin/TARGET-ldd

Note that it will need a "--root" argument, since ldd deals with
"dynamic" libraries (by definition), and those are located at
*runtime* -- but it's runtime on the ARM, which is *not* the same root
filesystem as exists on your cross-compile host!

(This is where the difference between "just a cross compiler" and "a
tool that builds an entire filesystem for a device" becomes painfully
obvious...)

Anyway.

In my setup, I build everything for a given PLATFORM in various
directories under /opt/cross/PLATFORM.  Specifically, I build the
cross-compiling toolchain into /opt/cross/PLATFORM/xtools, so i have:

/opt/cross/PLATFORM/xtools/bin/TARGET-ldd

Next, I have a directory where I build individual packages:

/opt/cross/PLATFORM/build/PACKAGE

(Which usually gets broken down further into a "src" and "build"
directory, to take advantage of the autotools and kconfig "build
outside of source tree" capabilities).

As packages are built, I "install" them into a "staging" area.  This
allows subsequent packages to find their prerequisites, and
(eventually) allows me to pick-and-choose when I go to build the final
root filesystem.  This staging "root directory" is:

/opt/cross/PLATFORM/stage

(Lots of "./configure --prefix=/ ; make ; make install
DESTDIR=/opt/cross/PLATFORM/stage" type things going on there.)

Finally, I build a full root filesystem for the target device.  This
is done by first creating a "minimal root" with just the custom
binaries I need, and then calling the "...-populate" script; in my
case, it is

/opt/cross/PLATFORM/xtools/bin/TARGET-populate \
  -s /opt/cross/PLATFORM/root-min \
  -s /opt/cross/PLATFORM/root

This works by scanning for dynamically linked files, finding the
prerequisites for those files, copying them to the destination root,
and repeating until there are no unsatisfied dependencies.

(If you care about the rest of the story, I then take the final root,
make a copy for live / NFS use, then whittle down the root (stripping
binaries, removing unused test binaries, etc, before building an
initramfs which I eventually write into flash on my device.)

After the "TARGET-populate" script is done, you can use the
destination directory as the "--root" argument to the "TARGET-ldd"
command:

$ cd /opt/cross/PLATFORM/live
$ ../xtools/bin/TARGET-ldd --root=. bin/my-main-app
        libdl.so.2 => /lib/libdl.so.2 (0xdeadbeef)
        libc.so.6 => /lib/libc.so.6 (0xdeadbeef)
        ld.so.1 => /lib/ld.so.1 (0xdeadbeef)
        libpthread.so.0 => /lib/libpthread.so.0 (0xdeadbeef)
        librt.so.1 => /lib/librt.so.1 (0xdeadbeef)
        libstdc++.so.6 => /lib/libstdc++.so.6 (0xdeadbeef)
        libm.so.6 => /lib/libm.so.6 (0xdeadbeef)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xdeadbeef)

To get back to what I started with, if I try this with the default ldd
on my system:

$ ldd bin/my-main-app
	not a dynamic executable

Although 'file' does recognize it:

$ file bin/my-main-app
bin/my-main-app: ELF 32-bit MSB executable, PowerPC or cisco 4500,
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
3.0.43, with unknown capability 0x41000000 = 0x11676e75, with unknown
capability 0x10000 = 0x90401, not stripped

And that should answer your second question:

> However, the *-populate? Will need a bit of explaining if you please.

It makes sure that the root filesystem *on the target* has all the
dependencies required at runtime.

HTH,
t.

--
For unsubscribe information see http://sourceware.org/lists.html#faq