[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Using Qt debug libraries without configure and qmake



On Tue, 15 Nov 2011 19:12:10 +0100
Malte Forkel <malte.forkel@berlin.de> wrote:

> I need your advise on how to deal with the way Debian packages the debug
> version of Qt libraries.

Debugging symbols exist in the libqt4-dbg package.

When building your own code, it is just a case of ensuring that the
flags are passed to the compiler, as normal. It has nothing to do with
pkg-config. The Makefile is broken. Check the actual output using
objdump and file.

When building packages for Debian, it's down to debian/rules and
arguments to dh_strip. Check the source of any number of dbg packages
already in Debian.

> I'm trying to package an existing software that includes a small Qt
> application. The software is not using autotools or qmake but fixed
> Makefiles. Building the release version is accomplished by lines like
>    CXXFLAGS += $(shell pkg-config --cflags QtCore)
>    LIBS +=  $(shell pkg-config --libs QtCore)
> Building the release version of the sofware works fine.

Those lines have no effect on whether the debug or release version is
built. That comes down to the use of strip - and you always want the
debug symbols in every build, let the Debian packaging sort out the
rest.

> Alternatively, when building a debug version, the above lines are
> replaced by
>    CXXFLAGS += $(shell pkg-config --cflags QtCore_debug)
>    LIBS +=  $(shell pkg-config --libs QtCore_debug)

Broken. There is no such .pc file for pkg-config, hence the errors.
Don't build a "release" and "debug" version, it makes no sense. There
is one version which gets stripped to retain the debug symbols in a
useful manner.

Fix the rest of the flags. In most cases, what you're thinking of as
the "release" build may actually contain debug symbols which dh_strip
would then put into a dbg package. What matters (the only thing
which matters) is exactly what is passed to g++.

When building for local development, always retain the debug symbols to
make life easier. Then when building a package, let the normal Debian
packaging rules retain the debug symbols until dh_strip is called to
put the detached symbols into the -dbg package.

Don't strip in the upstream build. Just don't. Ever.

What you think of as a "release" build is just broken.

> I have installed libqtcore4, libqt4-dev and libqt4-dbg in the build
> environment. Looking at the files in these packages, I noticed that they
> provide /usr/lib/libQtCore.so.4.4.3 and
> /usr/lib/libQtCore.so.4.4.3.debug, but not
> /usr/lib/libQtCore_debug.so.4.4.3. Also, there is

Check the contents of libqt4-dbg with 'dpkg -L libqt4-dbg' - that's
where the symbols live, exactly where gdb expects to find them. That's
the only useful thing to do with debug symbols anyway - let gdb find
them.

/usr/lib/debug/usr/lib/libQtGui.so.4.7.3
/usr/lib/debug/usr/lib/libQtCore.so.4.7.3
etc.

> What should I do to specify that the debug versions of the libraries are
> used?

You don't. You build your software with debugging symbols and then gdb
finds the debug symbols from the dbg packages directly. Packaging takes
care of the rest.

g++ -c -pipe -I../lib -g -I/usr/include/
Building with debugging symbols intact for later extraction via
dh_strip or use directly in gdb

$ file lib/libtextwidget.so.2.1.0 
lib/libtextwidget.so.2.1.0: ELF 64-bit LSB shared object, x86-64,
version 1 (SYSV), dynamically linked, BuildID
[sha1]=0xaca25b93845a468cc3f696cd7b796ada47d89226, not stripped

Clearly indicates that the debug symbols are available.

$ gdb ./bin/textwidget
Reading symbols
from /.../textwidget/bin/textwidget...done.
(gdb) 



-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpZOMrIc7oZY.pgp
Description: PGP signature


Reply to: