Posts Tagged autotools

Handling unit test with C++ visibility=hidden

Recently I started working on the libbash project. I will write several articles talking about it in future. Now I’d just like to write something about the problem we encountered during development.

Our project will be a shared library. The C++ visibility support could improve the overall performance. Put simply, it hides most of the ELF symbols which would have previously (and unnecessarily) been public. Well it’s good for the library, it’s not good for unit tests(namely gtest) because they need to know the symbols.

Of course we don’t want  the unit tests to be part of our library. So we need to find some way to let the unit test know the symbols and separate them into different automake targets. Our first solution is to use hidden visibility for the library and create an internal target with default visibility for the unit test. However, that requires compiling the source code twice. Finally Petteri Räty come with a solution (He is too busy to write a post :P):

libcppbash_la_SOURCES = blah
libcppbash_la_CXXFLAGS = $(AM_CXXFLAGS) -fvisibility=hidden -fvisibility-inlines-hidden

cppunittests_SOURCES = blah
cppunittests_LDADD = $(GTEST_LIBS)
cppunittests_LDFLAGS = -static

Here’s his explanation:
libtool by default builds both a shared and a static library for our project. This is why you see it building things twice (with PIC and without). Giving -static to libtool is just telling it to use the static version. Using the static version means everything ends up in the unit test binaries.


, , ,


Debug libtool program with gdb

libtool program is a shell script that can’t work with gdb.Here is an example:
$ ls -l check_ifnet
-rwxr-xr-x 1 gentoo gentoo 4269 Aug 18 20:46 check_ifnet
$file check_ifnet
check_ifnet: POSIX shell script text executable

For libtool programs, the shared libraries are put into .lib directory and that script sets up the running environment (See more information I find that many people manually copy the shared libraries for debugging purpose. That’s not quite convenient.

I have two ways to test these kind of programs with gdb:

  1. edit the program and change this line “exec “$progdir/$program” ${1+”$@”}” to “gdb “$progdir/$program” ${1+”$@”}”. Then run the program.
  2. libtool –mode=execute gdb your_program (This one is better)

, , ,