How to debug a program wrapped in a libtool script?

Question

I have a project involving

• shared libraries ie: mylib.so
• (test) program using these shared libraries ie: test_mylib

When I try to run gdb on test_mylib, it prints:

"test_mylib": not in executable format: File format not recognized

When I use the real program (.libs/test_mylib) directly instead, it still complains:

.libs/test_mylib: can't load library 'libhello.so.0'

How Can I run gdb to debug my program ?

Diplodocus

Answer 1

This is problem I ran into a couples of days ago and there is no generic answer on SO yet. Only special cases. Here is the answer I found on this page: http://www.gnu.org/software/libtool/manual/html_node/Debugging-executables.html

Until the program is installed, the system does not know where to look for the shared objects. They usually lies in .libs sub-directory of their source folder.

Libtool generates a convenience script to allow debugging before the actual installation is done (who wants to install buggy software before, debug it after?)

Fortunately, the generated script provides a helper for this:

libtool --mode=execute gdb test_mylib

Diplodocus

On an OS X machine, I get error: libtool: unknown option character `-' in: --mode=execute (my workaround was to install to a prefix, but perhaps --disable-shared as mentioned below is simpler in the long run) – Egad

Answer 2

The solution recommended by the libtool docs is to use static linking during development, as I decribed at: Build libtool application with static linking to local components

To do this, use the --disable-shared option to the ./configure script.

For example:

./configure --enable-debug --disable-shared

Now the generated executable is a directly executable binary rather than a libtool script.

This has the added benefit of roughly halving the build time.

Parole

Other background info without the --disabled-shared solution: autotools.io/libtool/wrappers.html and gnu.org/software/libtool/manual/html_node/… – Parole