libtool + gdb, a cure for pain

I finally got tired of misinchanting "gdb mumble .libs lt --args foo bar mumble" and dropped this into my ~/bin as lgdb:

#!/bin/bash
prog=$1
shift
exec gdb --args $(dirname $prog)/.libs/lt-$(basename $prog) "$@"

I am aware of the libtool gdb idiom, but that appears to have been deprecated. There is a current of thought within autotools people that abhors concision. I do not understand it.

(As long as I'm ranting, I wish that libtool would make the shell script + relinking case secondary to the binary case, if it is at all necessary.)

I hope this post is as superfluous as the last, for the world if not for my ego.

related articles

8 responses

  1. James Henstridge says:

    The following should work: "libtool --mode=execute gdb programname". This is what "libtool gdb" was shorthand for, and I'd be surprised if they removed the --mode=execute feature.

    Given that it acts a a pure prefix, you could use it as an alias rather than a shell script.

  2. lamby says:

    That's not a shell script, it's a Bash script.

  3. Dan Winship says:

    > (As long as I'm ranting, I wish that libtool would make the shell script + relinking case secondary to the binary case, if it is at all necessary.)

    It's necessary if you're building a library that you already have installed, because if you don't set LD_LIBRARY_PATH, the newly-built program will dynamically link against /usr/lib/libmumble.so rather than ../libmumble/.libs/libmumble.so like you wanted.

    Then again, maybe if you build with --enable-maintainer-mode, it could just build the working-directory copy with the mangled library path automatically, and then relink it with the standard library path only when you do "make install"...

    Anyway, knowing the "libtool --mode=execute" idiom is useful because you can use it with things other than gdb too (strace, valgrind, etc).

  4. Andy Wingo says:

    James, you're right as usual -- I should probably use that instead of poking .libs. It will also take care of making sure that the lt-foo is there, as it is not there until it is first run.

    Dan, it seems that once the lt-foo executable is created, it is indeed linked to the in-tree libs. So there does not actually seem to be a need for the shell script at all, given that libtool controls the installation process and can relink then anyway. (AM_MAINTAINER_MODE is sortof-deprecated too, in case you hadn't heard.)

    Lamby. Picking nits is entertaining but you must take more care. Your statement is vague ("That"? I assume you refer to my script?), incorrect (Bash is indeed a shell), and misguided (I never called it a shell script).

  5. Benoît Dejean says:

    Or use Nemiver !

  6. Baptiste says:

    Yep, Nemiver supports libtool wrapper in latest release.

  7. Will Thompson says:

    Andy: I think Lamby was picking James' nits, not yours. :)

  8. Andy Wingo says:

    Will: Are you picking my nits? ;-)

Comments are closed.