Five little suggestions for working on GNOME libraries

The GNOME OPW for Summer 2012 is approaching to the end. By working with the code of GUPnP through the internship, I have learned a lot about C programming with GLib/GObject. I think it is a great time to share some from what I learned to everyone, especially the beginners.

Here I collect five small suggestions focusing on coding:

  1. Avoid the trailing white space in your code and patch. Set your editor to be aware of the unnecessary white spaces at the end of line. Git doesn’t like them nor your mentor. If you use Vim, you can look at this page.

  2. Use --enable-shared=no during the configure phase to disable the build of shared library. This makes the test programs under tests directory statically linked to the target library. Otherwise the test programs will be Bash wrapper scripts. Doing so make it easier when you use gdb to load the test programs.

  3. Use CFLAGS=-g in the configure phase to generate the debugging info. Even though you may find configure --help shows you an option called --enable-debug, it basically will convert to -g -O3 for gcc. This -O3 will optimize your code and make it hard to track the execution in gdb.

  4. Combine your local commits into a single patch. After finishing a specific feature or fixing a particular bug, you may have many local commits in your Git commit tree. You may also have merges from the upstream repository. I find this link is extremely helpful to form a single patch from the mess.

  5. Use DevHelp. Even though you might prefer to the online documentation, you should give DevHelp a try. It is more convenient and faster. It can only show the documentation you are interested.

All right. That is it. Hopefully you will find them helpful.


13 thoughts on “Five little suggestions for working on GNOME libraries

  1. 2 is wrong, to debug an in-build-tree binary that links to a shared library you do:

    libtool –mode=execute gdb test/the-binary

    In fact, i have a shell alias like:
    alias lgdb=’libtool –mode=execute gdb’

    then i can just
    lgdb test/the-binary

    Using shared linking is just a pain.

  2. (2) Don’t use static linking, but create a wrapper script or an alias in bash named lgdb that just runs libtool –execute $@

    (3) My CFLAGS are “-g -O0 -fno-inline -fno-omit-frame-pointer”
    -O0 turns off all optimizations (in particular code reordering)
    -fno-inline does not inline functions, which means gdb will always give a proper stack trace
    -fno-omit-frame-pointer helps older profiling tools (most notably sysprof) generating stack traces.

    (5) I stopped using devhelp for online documentation for one single reason: I can link to online docs in chat discussions. Oh, and the fact that Google Search (with is better than devhelp helps, too (It finds typos, for example).

  3. Regarding #2, there’s an easy way around (without requiring static linking), IIRC:

    $ libtool –mode=execute gdb test/mytest

    (Learned that one on #gnome-hackers back in the days…)

  4. As for the 4th tip… have you tried git rebase -i HEAD~5 ? It allows you to reorder, remove, merge, split, amend, the last 5 commits in an interactive way (it loads your $EDITOR and allows you to play with the commits).

    You should try it, it’s way faster and more powerful (but be aware of more powerful is also more risky if you delete a line you didn’t want to, for that look at git reflog 😉

    Great tips!!

  5. Hey, this is really useful info!

    One thing, though – you don’t need to force static linking to be able to debug the tests. Instead, you can run:

    libtool exec gdb mytest

    and it will run gdb on the real binary, which is the same as doing:

    gdb .libs/lt-mytest

  6. Using –enable-shared=no isn’t very pretty. If you want to debug a prorgam that is hiding behind a libtool wrapper, you can just use: libtool –mode=execute gdb path/to/libtool_wrapped_program

  7. Hello,

    some additional suggestions:

    “Use –enable-shared=no during the configure phase to disable the build of shared library.”
    It’s not really necessary; some configure scripts even disable this option nowadays. Instead, I prefer to:
    * create an alias, for instance: alias lgdb=”libtool –mode=execute gdb –args”. You can add it to your ~/.bashrc or ~/.bash_aliases file.
    * now you can just invoke: “lgdb progname arguments”.

    “Use CFLAGS=-g in the configure phase to generate the debugging info.”
    It’s better to specify CFLAGS=”-g3 -O0″. “-g3” will enable additional debug information, for instance to expand macros in the debugger. And “-O0” will make sure to override any previous instance of “-Osomething” in the command line — sometimes “-O3” is added automatically because of the Makefile.

    Keep up the good work!

  8. Eeek. #2 is not really a good idea, because if you’re working on say glib, it will break your ability to install the shared libraries and use them to test *other* things.

    To run gdb on an uninstalled test program:

    $ libtool –mode=execute gdb –args ./testprogram –some-test-args

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s