On 3/29/2019 9:55 PM, Bruce Dubbs via lfs-dev wrote:
On 3/29/19 5:35 PM, Cindy-Sue Causey via lfs-dev wrote:
On 3/29/19, Daniel Schepler via lfs-dev
<[email protected]> wrote:
On Fri, Mar 29, 2019 at 9:00 AM Bruce Dubbs via lfs-dev
<[email protected]> wrote:
Just for comparison, Arch does not create .dbg files and does not use
--enable-gnu-build-id.
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/glibc
On further examination, it looks like the actual gcc configure flag is
--enable-linker-build-id. And I do see that being activated.
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gcc
I can't answer to the question of creating .dbg files.
--
Daniel Schepler
I'm out of my league here, but I'm stepping out on that very thin limb
(again) because you mentioned "dbg". I had already been attempting
some more self-education with previous knowledge of existing "-dbg"
archives in mind as I searched around.
In response to the currently very last post in this LFS thread, I just
found the following about generating dbg packages as written by a
self-described "student":
https://people.debian.org/~osamu/fun2prog.html#_detached_debugging_symbols
Found a few other things while searching around to see if I was at
least partially understanding your conversation here. That was
well-spent time because I've installed "-dbg" files that were
"Suggested" packages, just never had a usage case to actually work
with them to know their importance.
I just tried a Debian "apt-cache search dbg" and received back a HUGE
list in response. Most end in that "-dbg" and then several end with
"-dev". When "gcc" is included in that search (solely because it's
mentioned in this thread), "libgcc1-dbg" popped up with an extremely
short description:
"Description-en: GCC support library (debug symbols)
Debug symbols for the GCC support library."
In trying to further self-educate about your current discussion, I
next tried an Internet search for "debian install package debugging
information".
From Debian: AutomaticDebugPackages (presents itself as tl;dr version)..
https://wiki.debian.org/AutomaticDebugPackages
My initial grasp is that at least some find community available "-dbg"
files to be underused and overly mirrored thus wasting precious
volunteer mirror disk space. Additionally, it is suggested that
necessary *manual* attention to separate dbg packages' existences is a
potential or real waste of time and resources.
Ubuntu pulled up separately for that same Internet search...
https://wiki.ubuntu.com/Debug%20Symbol%20Packages
I next tried the originally proffered "enable-gnu-build-id". That
search suggested "enabled-gnu-build-id" which did NOT work. In fact,
neither did, and I now see that's been updated. On a whim, though, I
used just "gnu-build-id" which brought up Redhat in with others
sounding possibly at least slightly on topic.
If I'm completely off-track, my apologies. That reference to .dbg
packages empowered me to go ahead and poke my nose in. Maybe something
in the above will help one way or the other since there are more than
a few references to dbg packages and debugging. :)
Cindy :)
* going back into lurk-n-learn mode *
Thank you for your input.
One thing users need to understand is what debugging symbols are. They
are used by developers, usually via the gnu debugger gdb, to associate
source lines of code with the associated binary executable code.
In LFS we strip out debugging symbols at the end of Chapter 6 to save
space and incrementally decrease loading time. Usually the symbols are
much larger than the actual code. For example
-rwxr-xr-x 1 root root 1.8M Feb 7 03:39 /lib/libc-2.29.so
-rwxr-xr-x 1 root root 17M Feb 7 03:39 /lib/libc-2.29.so.dbg
See
http://www.linuxfromscratch.org/lfs/view/stable/chapter06/strippingagain.html
Most packages in LFS and BLFS build with debugging information included.
That's why we give stripping information again in BLFS:
http://www.linuxfromscratch.org/blfs/view/stable/introduction/notes-on-building.html#stripping
Normally separate .dbg files are only used when the base package is
loaded by the debugger, but if not stripped out, are loaded if they are
included in the base file.
Also note that in your references you give are to commercial distros
like fedora, ubuntu, debian, etc. They generally break library
packages into parts and do not install the -dev (packages wih headers,
.pc files, etc) or .dbg files by default. Indeed most distros I see
don't install many build tools either (gcc, make, autotools, etc) by
default.
For LFS, we keep a few .dbg files around for users that run regression
tests when building packages. Some packages need these .dbg files, but
only when running tests.
The more important part IMO, is that it is shown in the book _how_ to do
this. The examples of how to separate the .dbg files and where to store
them are given in LFS, but regression tests are not the only reason to
keep them. In fact, the initial list that we came up with (to avoid
being stripped) was specific to gdb, so that you aren't completely lost
in the woods when you need it. The original impetus for this was a
comment in Arch's PKGBUILD for GCC. Then Armin jumped in with the
necessary objcopy commands, and I believe it was Bruce who made the
mailing list babble sensible and added all of it to the book. I was
unable to locate the discussion in the archive, but it was prior to
November 2017 (I made mention of it to Ken on an unrelated topic
suggesting that it was a few months prior), but other libs (atomic, itm,
and quadmath I think) were later discovered and added to account for
regression tests well after the instructions were added about separating
the debugging symbols. Also, most distros do provide them easily by some
method, including Arch, which was shown as an example earlier of one
that does not. This is done by adding the 'debug' flag to makepkg's
OPTIONS variable (you also have to add DEBUG_C{,XX}FLAGS values
including at least '-g'), but you do have to rebuild the packages
yourself unless you are using a private repo.
--DJ
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
