FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-15-2011, 05:12 PM
Malte Forkel
 
Default Using Qt debug libraries without configure and qmake

Hi,

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

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.

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)
Building the debug version fails with errors like
Package QtCore_debug was not found in the pkg-config search path.
Perhaps you should add the directory containing `QtCore_debug.pc'
to the PKG_CONFIG_PATH environment variable
No package 'QtCore_debug' found

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
/usr/lib/pkgconfig/QtCore.pc, but no /usr/lib/pkgconfig/QtCore_debug.pc
(or /usr/lib/pkgconfig/QtCore.debug.pc). Debian seems to use its own way
of packaging the debug versions.

As far as I can tell after some looking around, this might be no problem
when using a configure and qmake. Unfortenatey, upstream does not.

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

Thanks in advance,
Malte



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: j9ua1r$m34$1@dough.gmane.org">http://lists.debian.org/j9ua1r$m34$1@dough.gmane.org
 
Old 11-15-2011, 06:02 PM
Neil Williams
 
Default 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/
 
Old 11-15-2011, 06:26 PM
Simon McVittie
 
Default Using Qt debug libraries without configure and qmake

On Tue, 15 Nov 2011 at 19:02:48 +0000, Neil Williams wrote:
> 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++.

Some packages/build systems do distinguish between a "debug" and "release"
build, and actually compile different code for the two (e.g. python2.7-dbg
has a lot of reference-count-debugging goo which just doesn't exist in
python2.7), or do things like changing the level of optimization.
I believe this is particularly popular in things originating on Windows
(iirc MSVC++ has release- and debug-mode runtime libraries, which are not
the same).

For instance, the "release" version might build with -NDEBUG
(disable assert(3)), -DG_DISABLE_ASSERTS (the equivalent for GLib), or even
-DG_DISABLE_CHECKS (the "break my app" flag). In some packages (like Python),
the debug version even has a different ABI (again, for the intrusive
reference-count-debugging stuff, which makes all your objects a bit larger).

I personally think this sort of thing should be avoided wherever possible -
not least because you run the risk of having bugs that can be reproduced
with the release version but not the debug version - but it's something that
happens, unfortunately including packages I maintain.

In Debian, we build everything with debug symbols (-g), but usually using the
code paths that would normally be considered a "release" version.

CMake formalizes this by having "Debug", "Release" and "RelWithDebInfo"
values for CMAKE_BUILD_TYPE: the one normally used in Debian is
RelWithDebInfo.

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111115192610.GB29176@reptile.pseudorandom.co.uk" >http://lists.debian.org/20111115192610.GB29176@reptile.pseudorandom.co.uk
 
Old 11-17-2011, 11:00 AM
Malte Forkel
 
Default Using Qt debug libraries without configure and qmake

Thanks for your help, guys!

Now that I (hopefully) understand the Debian approach to providing
debugging information, its obvious why I didn't find any useful
information before: My questions were wrong.

There are two questions which I'd still like to ask:
- Is there any summary on how to provide debugging information when
packaging in the Debian manuals that I overlooked?
- What do you mean by
> Don't strip in the upstream build. Just don't. Ever.
Is it that any stripping should be initiated from debian/rules, but
should never be performed by the upstream Makefiles?

Malte



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: ja2t16$gip$1@dough.gmane.org">http://lists.debian.org/ja2t16$gip$1@dough.gmane.org
 
Old 11-17-2011, 11:19 AM
Simon McVittie
 
Default Using Qt debug libraries without configure and qmake

On Thu, 17 Nov 2011 at 13:00:40 +0100, Malte Forkel wrote:
> - What do you mean by
> > Don't strip in the upstream build. Just don't. Ever.
> Is it that any stripping should be initiated from debian/rules, but
> should never be performed by the upstream Makefiles?

Always build with -g, and never discard the debug symbols entirely.
The Debian way to strip debug symbols out of the "normal" library
is usually done with dh_strip, part of debhelper:

* first, objcopy(1) the debug symbols into files that will end up installed to
/usr/lib/debug by the -dbg binary package - gdb knows how to find them
there automatically

* then and only then, use strip(1) to remove the debug symbols from the
"main" version of the library

The files in /usr/lib/debug are not complete libraries: they contain
the debug symbols which were previously in the corresponding library
in /usr/bin, but they do not contain any executable code.

This means the main library package is small (because it only contains the
executable code), but can still be debugged by installing the corresponding
-dbg package (which contains the corresponding debug symbols). While
debugging your program or library, gdb reads both the main library and its
debug symbols, and behaves as if the debug symbols had been in the main
library all along.

I've been saying "library", but some packages do the same for binaries
(e.g. dbus-dbg contains /usr/lib/debug/usr/bin/dbus-daemon, which contains
the debug symbols for /usr/bin/dbus-daemon, without duplicating the
executable code).

The dh_strip source code is very readable; have a look at it if you want
more detail.

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111117121958.GA7913@reptile.pseudorandom.co.uk"> http://lists.debian.org/20111117121958.GA7913@reptile.pseudorandom.co.uk
 
Old 11-17-2011, 12:11 PM
Philip Ashmore
 
Default Using Qt debug libraries without configure and qmake

On 17/11/11 12:19, Simon McVittie wrote:

On Thu, 17 Nov 2011 at 13:00:40 +0100, Malte Forkel wrote:

- What do you mean by

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

Is it that any stripping should be initiated from debian/rules, but
should never be performed by the upstream Makefiles?

Always build with -g, and never discard the debug symbols entirely.
The Debian way to strip debug symbols out of the "normal" library
is usually done with dh_strip, part of debhelper:

* first, objcopy(1) the debug symbols into files that will end up installed to
/usr/lib/debug by the -dbg binary package - gdb knows how to find them
there automatically

* then and only then, use strip(1) to remove the debug symbols from the
"main" version of the library

The files in /usr/lib/debug are not complete libraries: they contain
the debug symbols which were previously in the corresponding library
in /usr/bin, but they do not contain any executable code.

This means the main library package is small (because it only contains the
executable code), but can still be debugged by installing the corresponding
-dbg package (which contains the corresponding debug symbols). While
debugging your program or library, gdb reads both the main library and its
debug symbols, and behaves as if the debug symbols had been in the main
library all along.

I've been saying "library", but some packages do the same for binaries
(e.g. dbus-dbg contains /usr/lib/debug/usr/bin/dbus-daemon, which contains
the debug symbols for /usr/bin/dbus-daemon, without duplicating the
executable code).

The dh_strip source code is very readable; have a look at it if you want
more detail.

S

While useful, debug symbolsonlyhelp so much.
On some other distributions the debugging symbols package includes the source code
and kdbg integration so that kdbg can prompt you to download the dbg package while
you're debugging an app.

Even with this, optimization can make the instruction pointer appear to dart all
over the place when single stepping, and also optimizes out variables that you
would sometimes really like to know the value of.

Maybe a "noopt" package variant would help here, but that would nearly double the
number of package builds.

Wasn't there a gcc objective to tame this with release builds?

Looking at "Re: Could the multiarch wiki page be explicit about pkgconfig files?"
I've seen debugging symbols point to source files all over the place, depending
on who or how the package in question was built, none of which pointed to
/usr/lib/debug or similar.

Developers new to Debian can't fail to be surprised by this.

Regards,
Philip Ashmore


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EC507EC.3000403@philipashmore.com">http://lists.debian.org/4EC507EC.3000403@philipashmore.com
 
Old 11-17-2011, 01:56 PM
Neil Williams
 
Default Using Qt debug libraries without configure and qmake

On Thu, 17 Nov 2011 13:11:08 +0000
Philip Ashmore <contact@philipashmore.com> wrote:

> While useful, debug symbolsonlyhelp so much.
> On some other distributions the debugging symbols package includes the source code
> and kdbg integration so that kdbg can prompt you to download the dbg package while
> you're debugging an app.
>
> Even with this, optimization can make the instruction pointer appear to dart all
> over the place when single stepping, and also optimizes out variables that you
> would sometimes really like to know the value of.
>
> Maybe a "noopt" package variant would help here, but that would nearly double the
> number of package builds.
>
> Wasn't there a gcc objective to tame this with release builds?
>
> Looking at "Re: Could the multiarch wiki page be explicit about pkgconfig files?"
> I've seen debugging symbols point to source files all over the place, depending
> on who or how the package in question was built, none of which pointed to
> /usr/lib/debug or similar.
>
> Developers new to Debian can't fail to be surprised by this.

The path doesn't matter that much, as long as the debugger can find a
filename which at least matches the end of the path. i.e. work
backwards and use the best match. This isn't down to Debian, it is down
to how gcc and gdb work together and how developers need to use gdb or
other tools frontending gdb to set the path to the unpacked sources.
Some tools do it better than others, especially when considering how to
follow a call down through a couple of different libraries.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 11-17-2011, 07:01 PM
Philip Ashmore
 
Default Using Qt debug libraries without configure and qmake

On 17/11/11 14:56, Neil Williams wrote:

On Thu, 17 Nov 2011 13:11:08 +0000
Philip Ashmore<contact@philipashmore.com> wrote:


While useful, debug symbolsonlyhelp so much.
On some other distributions the debugging symbols package includes the source code
and kdbg integration so that kdbg can prompt you to download the dbg package while
you're debugging an app.

Even with this, optimization can make the instruction pointer appear to dart all
over the place when single stepping, and also optimizes out variables that you
would sometimes really like to know the value of.

Maybe a "noopt" package variant would help here, but that would nearly double the
number of package builds.

Wasn't there a gcc objective to tame this with release builds?

Looking at "Re: Could the multiarch wiki page be explicit about pkgconfig files?"
I've seen debugging symbols point to source files all over the place, depending
on who or how the package in question was built, none of which pointed to
/usr/lib/debug or similar.

Developers new to Debian can't fail to be surprised by this.

The path doesn't matter that much, as long as the debugger can find a
filename which at least matches the end of the path. i.e. work
backwards and use the best match. This isn't down to Debian, it is down
to how gcc and gdb work together and how developers need to use gdb or
other tools frontending gdb to set the path to the unpacked sources.
Some tools do it better than others, especially when considering how to
follow a call down through a couple of different libraries.

You mean as long as the user knows where the sources are supposed to be
installed, such as

/usr/src/foo-1.2/src/foo-widget.cpp
, presuming they are even installed or the user downloaded (the matching
version of) them.


The debugger will only find the file itself if the debugging information
contains an absolute path.


The choice of root folder, for example /usr/src/foo-1.2 or
/usr/src/{build-id}/foo-1.2

is Debian specific.

The tools which Debian supplies should also use it so that the sources
get installed there.


Hopefully one day, the Debian build tools will alter the debugging
information to point to this
location regardless of where the sources really were when the package
was built.


Could this be a build option?

Also, if source packages from deb-src could be "installed", populating
/usr/src then that would

avoid having to package "source" binary packages, and be version-safe.

Philip


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EC56826.1070009@philipashmore.com">http://lists.debian.org/4EC56826.1070009@philipashmore.com
 
Old 11-17-2011, 11:07 PM
Neil Williams
 
Default Using Qt debug libraries without configure and qmake

On Thu, 17 Nov 2011 20:01:42 +0000
Philip Ashmore <contact@philipashmore.com> wrote:

> On 17/11/11 14:56, Neil Williams wrote:
> > The path doesn't matter that much, as long as the debugger can find a
> > filename which at least matches the end of the path. i.e. work
> > backwards and use the best match. This isn't down to Debian, it is down
> > to how gcc and gdb work together and how developers need to use gdb or
> > other tools frontending gdb to set the path to the unpacked sources.
> > Some tools do it better than others, especially when considering how to
> > follow a call down through a couple of different libraries.
> >
> You mean as long as the user knows where the sources are supposed to be
> installed, such as
> /usr/src/foo-1.2/src/foo-widget.cpp

$ apt-get source

That puts the unpacked source exactly where the user expects - in the
current directory.

You'd need to be root to put the unpacked source into /usr/src using
apt-get source and that is NOT good advice.

There are binary packages which *install* the source into /usr/src but
that isn't the default. This is about getting the source of typical,
routine Qt applications and libraries. *That* is what you get from
deb-src URL's. Packages which unpack to /usr/src will come from deb
repositories NOT deb-src.

> , presuming they are even installed or the user downloaded (the matching
> version of) them.

apt-get source - it always gives you the matching version, that's the
point.

> The debugger will only find the file itself if the debugging information
> contains an absolute path.

Not true. The debugger will look for the path you provide and try to
match the files according to the reverse lookup - much the same way as
patch.

> The choice of root folder, for example /usr/src/foo-1.2 or
> /usr/src/{build-id}/foo-1.2
> is Debian specific.

More commonly, /home/$USER/code/src/$PACKAGE etc.

> The tools which Debian supplies should also use it so that the sources
> get installed there.
>
> Hopefully one day, the Debian build tools will alter the debugging
> information to point to this
> location regardless of where the sources really were when the package
> was built.
>
> Could this be a build option?

No, because the actual location varies according to user preference.

I use /home/neil/code/debian/src or /home/neil/code/debian/qa/
or /home/neil/code/debian/rc, depending on why I'm debugging a
particular package. ./src/ for routine devleopment, ./qa/ for orphaned
packages and ./rc/ for release goals. Depending on exactly what is
going on, I could quite easily be debugging three different versions of
the same package in those directories and if I need to debug a fourth,
well it's trivial.

> Also, if source packages from deb-src could be "installed", populating
> /usr/src then that would
> avoid having to package "source" binary packages, and be version-safe.

Forget about /usr/src, it isn't useful for the majority of packages.
Arbitrary directories specified by the user are the only way to allow
developers to debug against a variety of dependencies and in a variety
of situations. /usr/src is a privileged path, source does not need a
privileged path and is usually far better in a user path.

Qt applications or libraries do NOT use /usr/src.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 11-18-2011, 11:12 AM
Philip Ashmore
 
Default Using Qt debug libraries without configure and qmake

On 18/11/11 00:07, Neil Williams wrote:

On Thu, 17 Nov 2011 20:01:42 +0000
Philip Ashmore<contact@philipashmore.com> wrote:


On 17/11/11 14:56, Neil Williams wrote:

The path doesn't matter that much, as long as the debugger can find a
filename which at least matches the end of the path. i.e. work
backwards and use the best match. This isn't down to Debian, it is down
to how gcc and gdb work together and how developers need to use gdb or
other tools frontending gdb to set the path to the unpacked sources.
Some tools do it better than others, especially when considering how to
follow a call down through a couple of different libraries.


You mean as long as the user knows where the sources are supposed to be
installed, such as
/usr/src/foo-1.2/src/foo-widget.cpp

$ apt-get source

That puts the unpacked source exactly where the user expects - in the
current directory.

You'd need to be root to put the unpacked source into /usr/src using
apt-get source and that is NOT good advice.

There are binary packages which *install* the source into /usr/src but
that isn't the default. This is about getting the source of typical,
routine Qt applications and libraries. *That* is what you get from
deb-src URL's. Packages which unpack to /usr/src will come from deb
repositories NOT deb-src.


, presuming they are even installed or the user downloaded (the matching
version of) them.

apt-get source - it always gives you the matching version, that's the
point.

presuming you've done apt-get upgrade, which requires elevated(root)
privileges.



The debugger will only find the file itself if the debugging information
contains an absolute path.

Not true. The debugger will look for the path you provide and try to
match the files according to the reverse lookup - much the same way as
patch.
so it won't find it itself based on the path provided in the debugging
information.

Sometimes it's far from obvious which package a source file belongs to.
It would be great if the debugger could tell you.



The choice of root folder, for example /usr/src/foo-1.2 or
/usr/src/{build-id}/foo-1.2
is Debian specific.

More commonly, /home/$USER/code/src/$PACKAGE etc.


The tools which Debian supplies should also use it so that the sources
get installed there.

Hopefully one day, the Debian build tools will alter the debugging
information to point to this
location regardless of where the sources really were when the package
was built.

Could this be a build option?

No, because the actual location varies according to user preference.

but unless you've built the package from source yourself, the debugging
information points to just one place - usually the location on the
machine that

built it, not very useful.

I use /home/neil/code/debian/src or /home/neil/code/debian/qa/
or /home/neil/code/debian/rc, depending on why I'm debugging a
particular package. ./src/ for routine devleopment, ./qa/ for orphaned
packages and ./rc/ for release goals. Depending on exactly what is
going on, I could quite easily be debugging three different versions of
the same package in those directories and if I need to debug a fourth,
well it's trivial.


Also, if source packages from deb-src could be "installed", populating
/usr/src then that would
avoid having to package "source" binary packages, and be version-safe.

Forget about /usr/src, it isn't useful for the majority of packages.
Arbitrary directories specified by the user are the only way to allow
developers to debug against a variety of dependencies and in a variety
of situations. /usr/src is a privileged path, source does not need a
privileged path and is usually far better in a user path.

Qt applications or libraries do NOT use /usr/src.

I'm not a Fedora fan, but that's exactly what they do.
It's a de-facto Debian decision not to standardize on any install path,
which is

bizarre.

Don't forget, some people have accounts on multi-user systems, and filling
their home directory with package sources is something they simply cannot do
for space reasons, and even if they could, it duplicates downloads and
storage.


Yes, I realise this isn't Qt specific.

With respect, have you had a look at
http://lists.debian.org/debian-devel/2011/09/msg00517.html
?

Philip


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EC64BB1.7000608@philipashmore.com">http://lists.debian.org/4EC64BB1.7000608@philipashmore.com
 

Thread Tools




All times are GMT. The time now is 04:05 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org