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.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
