Il 17/12/2012 11:11, Tomáš Chvátal ha scritto:
Hi lads,
lately I am having bit of problems from getting relevant debug info from users.
Since we already have splitdebug for quite time (and I suppose quite
few of us are using it) how about making it to default profiles
default enabled and add -g to default cflags. Currently it is only
enabled in the developer profile.
This results in 2 gb data in /usr/lib/debug for my system which is not
that bad with current disk sizes and it saves users quite some time
when i have to request them to recompile half of their system with
debug info just to get idea how to fix their issue.
I would go even for compressdebug feature but that one needs more time
as some packages like glibc fails to merge with it and you need newer
gdb to work with it.
Cheers
Tom
By the way gcc-4.8 will have support for -gsplit-dwarf, should be
something similar to split-debug, just done pre linking and with
different file names.
While I've no idea how this feature work, probably start planning would
be beneficial.
-gsplit-dwarf
Separate as much dwarf debugging information as possible into a
separate output file with the extension .dwo.
This option allows the build system to avoid linking files with
debug information.
To be useful, this option requires a debugger capable of reading
.dwo files.
Also thinking about this a bit more, seem a binpkg for debug stuff can
be interesting, similarly to how binary distro do.
rogue example implementation:
with FEATURE="buildpkg split-debug-pkg"
all the /usr/lib/debug and /usr/src/debug files are put in a separate
package debug/category/pn or similarly to sec-policy/selinux* debug/cat--pn
the user can then install debug packages at will, the dependancies
should work (and clone those of the real package) but not be mandatory.
how difficult would be to implement this in portage (keep in mind that
packages are coupled and should stay that way also for unmerge and
whatever)?
Would be possible to have FEATURE=" -buildpkg split-debug-pkg"?
A similar feature would be useful for linguas support but more difficult
to implement.
