Cfxtrjtrk

I am porting a large set of applications and libraries from Debian 7 to Ubuntu 16.04. This is a GNU autotools project, so libtool is involved. gdb cannot find the symbols for the majority of the shared libraries, even though I am building with options that have always worked for me before. I am wondering if anyone else has encountered this problem, and if so what recommendations they might have.

I am using gdb version Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1.

I am compiling with -g O0 and other compiler options. These options are consistently employed when building 12 libraries. Exactly one of them emerges from the build process with debugging symbols. We'll designate that one libA. (In the discussion below, is just a substitution for the project path.)

Leaving out many -I directives, the options being used are:

-g -O0 -Wconversion -Woverloaded-virtual -Wall -Werror -Wreturn-type - 

Wformat -Wparentheses -Wswitch -Wno-deprecated -Wsign-compare -fno- 

strict-aliasing -Wunused -D__STDC_LIMIT_MACROS -MT MyModule.lo -MD -MP 

-MF .deps/MyModule.Tpo -fPIC -DPIC -o .libs/MyModule.o

When I look at libA using gdb, file, and other utilities it looks fine.

u16dev01:(18:01:32):file libA.so.0.0.0                 ~/dev/product- 

<path>lib/liba/.libs

libA.so.0.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), 

dynamically linked, 

BuildID[sha1]=14dc765142914be4c32a07eaa1683b5b2a2f6dae, not stripped

The object files look like this:

u16dev01:(18:01:43):file AModule1.o                          

<path>/lib/liba/.libs

AModule1.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not 

stripped

If I open the shared library with gdb, I have symbols and I can list the code. If I open any of its .o files with gdb, I get symbols and can list code.

Of the remaining 11, the file command reports two as being SYSV and the other 9 as being GNU/Linux, for example:

u16dev01:(18:08:34):file libD.so.0.0.0                      

~/<path>/lib/.libs

libD.so.0.0.0: ELF 64-bit LSB shared object, x86-64, 

version 1 (GNU/Linux), dynamically linked, 

BuildID[sha1]=059733fbc888c3dce86eae21984ea82cddc5b0e9, not stripped

gdb sees no symbols when I open this library or any of its .o files. The file command also reports GNU/Linux for the .o files. There are no symbols.

There are two libraries which file reports as SYSV. Their .o files are also devoid of debugging information, and so are the libraries.

I renamed the strip program to preclude the possibility of the Makefiles from running strip, even though a careful search of compiler output told me it wasn't. So this is not a case of symbols being stripped after library build.

I tried to build a little test library, using the compiler options of my project. It builds a SYSV library and gdb loads debug symbols just fine.

objdump -g output is sparse in the cases when gdb can't load symbols.

I and a couple of my colleagues have been scratching our heads over this one for a few days now. Why does the build procedure produce viable symbols for only one of the libraries? There's nothing special about that library. Why are 9 of the remaining 11 reported GNU/Linux and 2 reported as SYSV? Why don't those 2 have symbols either?

Any ideas would be very appreciated.

The problem was eventually tracked down to a legacy custom m4 macro. It failed to detect a library package and clobbered its contribution to the variables that were written to Makefile.in for include paths. The result was a -I with no path in the sequence of many -I directives. Oddly this produced no error ... but it did seem to cause the -g option which immediately followed it to be "swallowed". (The result was a long list of -I paths which ended with "-I -g". It looks like this prevented g++ from processing the -g option.).

Correcting the erroneous m4 macro to produce a non-empty and valid include file path fixed the problem.

You need to use -g in your compile command. See the man page for gcc at the section titled: Options for Debugging Your Program
They have some cautions when used with the -O option.