Shared libraries

Your buildfile must tell the build process to include in the image all the shared objects required by the drivers you'll be running.

Including shared objects

All drivers require at least the standard C library shared object (libc.so). Since the shared object search order looks in /proc/boot, you don't have to do anything special. Just specify the name of the shared object on a line by itself; this means “include this file”.

Note: The system expects to find the runtime linker in a file called ldqnx.so.2. However, the runtime linker is currently contained in libc.so, so we need to create a process manager symbolic link to it.

The following buildfile snippet instructs the build process to include the C library shared object, and creates a symbolic link for ldqnx.so.2 to libc.so:

# include the C shared library
libc.so
# create a symlink called ldqnx.so.2 to it
[type=link] /usr/lib/ldqnx.so.2=/proc/boot/libc.so

Determining which shared objects you need

There are several ways to determine which shared objects you must include in your system image.

On the target

On the target system, you can use the ldd utility, or the DL_DEBUG environment variable.

The ldd (“list dynamic dependencies”) utility lists the shared objects required by the program you specify. For example:

# ldd `which ping`
/usr/bin/ping:
        libsocket.so.3 => /lib/libsocket.so.3 (0xb8200000) 
        libc.so.4 => /usr/lib/ldqnx.so.2 (0xb0300000)

You can set the DL_DEBUG environment variable. This causes the shared library loader to display debugging information about libraries as they're opened. For example:

# export DL_DEBUG=libs
# ping 10.42.110.235
load_object: attempt load of libsocket.so.3
load_elf32: loaded lib at addr b8200000(text) b822bccc(data)
dlopen("nss_files.so.0",513)
load_object: attempt load of nss_files.so.0
dlopen: Library cannot be found
dlopen("nss_dns.so.0",513)
load_object: attempt load of nss_dns.so.0
dlopen: Library cannot be found

For more information about the values for DL_DEBUG, see the entry for dlopen() in the QNX Neutrino C Library Reference.

On the host

The objdump utility displays information about the executables you're including in the image; look for the objects marked as NEEDED. For example:

$ ntox86_64-objdump -x x86_64/usr/bin/ping | grep NEEDED
  NEEDED               libsocket.so.3
  NEEDED               libc.so.4

The ping executable needs libsocket.so.3 and libc.so.4.

You then need to use objdump recursively to see what other shared objects these shared objects need:

$ ntox86_64-objdump -x x86_64/lib/libsocket.so.3 | grep NEEDED
  NEEDED               libc.so.4
$ ntox86_64-objdump -x x86_64/lib/libc.so.4 | grep NEEDED

The libsocket.so.3 shared object needs only libc.so.4, which, in turn, needs nothing.

Running executables more than once

If you want to run executables more than once, you need to specify the [data=copy] attribute for them. You can do this for a single executable; for example:

[data=copy] executable_1

Or, you can do this for all the executables that follow the attribute; for example:

# Copy code and data for all executables after this line
[data=copy]
...	
executable_1
executable_2
...
executable_n

Setting the [data=copy] attribute causes the data segment used by a program to be copied before it's used, so its contents won't be overwritten (see Buildfile syntax for more information about using buildfile attributes).