| View previous topic :: View next topic |
| Author |
Message |
Lemon-Lime
n00b
Joined: 27 Apr 2023
Posts: 58
|
 Posted: Thu Sep 26, 2024 12:56 pm Post subject: Splitdebug in make.conf |
 |
|
Hello Gentoo forums!
Quick question, I realized I have the following line in my make.conf:
| Code: |
(...)
#Enables tests
FEATURES="splitdebug"
(...)
|
If my memory serves me right (and with the help of the comment) I think I enabled that feature because I was doing python ebuild """"development""" (writing python ebuilds) and I needed to check the testing code.
However, for unrelated reasons, I found this article: https://wiki.gentoo.org/wiki/Debugging
Here it states that splitdebug installs debug information (in retrospect, the name is a bit telling). Now, does having this feature enabled globally mean that I am installing debug information for ALL the programs in my machine? Or am I under a misconception?
If that is the case, is it recommended? My intuition tells me that maybe it's a bit overkill and that it takes too much disk space.
Besides, if I run "gdb gimp" (for example) I don't get the souce code (with splitdebug by itself).
Would love to get some guidance. Thanks in advance.
Cheers! 
_________________
Crazy frog is the artist, not the song |
|
| Back to top |
|
 |
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22640
|
| Posted: Thu Sep 26, 2024 2:21 pm Post subject: |
|
|
Per man make.conf: | Code: | splitdebug
Prior to stripping ELF etdyn and etexec files, the debug‐
ging info is stored for later use by various debuggers.
This feature is disabled by nostrip. You should also
consider setting compressdebug so the files don’t suck up
a lot of space. For installation of source code, see in‐
stallsources. |
Therefore:- If you are not compiling with debug information (gcc CFLAGS option: -g, and various others near it; see info gcc for exhaustive detail), then the information split by this is fairly minimal, or even non-existent.
- If you are compiling with debug information, this will save the debug symbols, but not the source code. You can get backtraces and inspect the value of variables, which may be good enough, particularly if you have the source code open by hand elsewhere to let you follow along.
- Yes, global debug information can be very space intensive. You should only enable debug symbols for packages where you expect to use them. However, if you have the CPU time to spend generating them at emerge time, and sufficient disk space to store them, you could generate them globally. It won't hurt anything at runtime.
|
|
| Back to top |
|
|
Lemon-Lime
n00b
Joined: 27 Apr 2023
Posts: 58
|
| Posted: Thu Sep 26, 2024 6:13 pm Post subject: |
|
|
| Hu wrote: | | Therefore:[list][*]If you are not compiling with debug information (gcc CFLAGS option: -g, and various others near it; see info gcc for exhaustive detail), then the information split by this is fairly minimal, or even non-existent.[*] |
Great to know! Thank you very much. So I should be able to just leave it there, right?
| Hu wrote: |
Yes, global debug information can be very space intensive. You should only enable debug symbols for packages where you expect to use them. However, if you have the CPU time to spend generating them at emerge time, and sufficient disk space to store them, you could generate them globally. It won't hurt anything at runtime.
|
Great. I have replicated the wiki's advice in regards to package.env, so that information should only be stored for packages that are present in said directory AFAIAC. Correct??
Thank you very much Hu! 
_________________
Crazy frog is the artist, not the song |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2414
|
| Posted: Thu Sep 26, 2024 6:24 pm Post subject: |
|
|
| Lemon-Lime wrote: |
Great. I have replicated the wiki's advice in regards to package.env, so that information should only be stored for packages that are present in said directory AFAIAC. Correct??
|
Correct. But package.env can be and I recommend it be a directory, because you can have package.env/category/package in there and it better be ready to accommodate such a need, should it arise. Plus, it's way better to organize things into files inside package.env/use/et.c.
Also this: https://wiki.gentoo.org/wiki//etc/portage/package.env#.2Fetc.2Fportage.2Fpackage.env_must_be_a_directory_for_some_packages_to_work
Best Regards,
Georgi |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22640
|
| Posted: Thu Sep 26, 2024 6:49 pm Post subject: |
|
|
| Lemon-Lime wrote: | | Great to know! Thank you very much. So I should be able to just leave it there, right? |
Yes. |
|
| Back to top |
|
|
Lemon-Lime
n00b
Joined: 27 Apr 2023
Posts: 58
|
| Posted: Sun Sep 29, 2024 2:55 pm Post subject: |
|
|
Great!
Thank you both logrusx and Hu!
Have a great week
_________________
Crazy frog is the artist, not the song |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
