Optionally exclude libs needed for a sane debugger from stripping

[DJ Lucas]

A sane exclusion list for BLFS would be something like: "ld- libatomic libc- libcilkrts ligfortran libgo libgomp libitm libmpx libobjc libpthread libquadmath libsanitizer libstdc++ libthread_db libvtv"

These taken from Arch Linux PKGBUIDs and may not be all inclusive.

[DJ Lucas]

Will take a more thorough look at it later, just getting this into the bug tracker. Here is the goal, save for syntax variations (maybe xargs or + instead of \, or properly divide the list, etc.):

save_libs="ld- libatomic libc- libcilkrts ligfortran libgo libgomp libitm libmpx libobjc libpthread libquadmath libsanitizer libstdc++ libthread_db libvtv"

mkdir -p /tmp/dbg/{,usr/}lib

for lib in $save_libs
do
    find /usr/lib -name "${lib}*" -type f -exec cp {} /tmp/dbg/usr/lib \;
    find /lib -name "${lib}*" -type f -exec cp {} /tmp/dbg/lib \;
done

/tools/bin/find /usr/lib -type f -name \*.a \
   -exec /tools/bin/strip --strip-debug {} ';'

/tools/bin/find /lib /usr/lib -type f -name \*.so* \
   -exec /tools/bin/strip --strip-unneeded {} ';'

/tools/bin/find /{bin,sbin} /usr/{bin,sbin,libexec} -type f \
    -exec /tools/bin/strip --strip-all {} ';'

cp -av /tmp/dbg/lib/* /lib
cp -av /tmp/dbg/usr/lib/* /usr/lib
rm -rf /tmp/dbg

[bdubbs@…]

This appears to be a good thing to do, but I would implement it slightly differently. I'd create /var/dbg/lib and /var/dbg/usr/lib (the names of the directories are not particularly critical) and put the non-stripped files there. The user could then copy them to /lib and /usr/lib as needed or desired, but not copy back to the main /lib directories automatically.

We might even want to create a parallel set of directories for storage of the stripped libraries and a couple of scripts to copy one set or the other into /usr/lib and /lib.

This later suggestion would probably be better as a hint.

[DJ Lucas]

Replying to bdubbs@…:

This appears to be a good thing to do, but I would implement it slightly differently. I'd create /var/dbg/lib and /var/dbg/usr/lib (the names of the directories are not particularly critical) and put the non-stripped files there. The user could then copy them to /lib and /usr/lib as needed or desired, but not copy back to the main /lib directories automatically.

I don't particularly care where we put them. /var/dbg works for me as long as it doesn't break FHS/LSB. Make it optional of course, as it negates one of the reasons for stripping in the first place (saving space). I figure that the needed files are already in place, just save them in the event that they are needed later, rather than suggesting an unnecessary rebuild of glibc and/or gcc later in BLFS.

We might even want to create a parallel set of directories for storage of the stripped libraries and a couple of scripts to copy one set or the other into /usr/lib and /lib.

This later suggestion would probably be better as a hint.

I included the additional GCC language libraries in the above commands specifically for the case of the above, as you can always repeat the stripping commands after you are done using the debugger, and the additions don't hurt anything if they are not present.

Me personally, I'm more inclined to copy them back unconditionally (as above), i.e.: don't ever strip these libraries (the 'unless you are doing an embedded or space constrained build' is implied, but much more than stripping is involved in those targets anyway). If we really wanted to make it more integrated, we could create a 'strip-whole-system.sh' script and add a config file in /etc with a list of exclusions. Just append to the config file in BLFS. From my POV, however, just keeping a copy of the ones known to be needed for gdb and Valgrind seems sufficient for illuminating this particular dark corner for readers. Anything more would probably be unnecessary hand-holding.

[DJ Lucas]

I forgot to add, that if a user wants to debug a problem really deep, they have to rebuild all of the affected libs with -g anyway. This is specific to the core libs, avoid rebuilding of glibc and gcc.

[bdubbs@…]

I needed to get the debug libs on my current development system. It was a hassle.

-rwxr-xr-x 1 root root  1244312 Apr 21 15:35 ld-2.25.so
-rwxr-xr-x 1 root root   149232 Apr 21 15:03 ld-2.25.so.sav
-rwxr-xr-x 1 root root  2167232 Apr 21 15:36 libpthread-2.25.so
-rwxr-xr-x 1 root root   106096 Apr 21 15:04 libpthread-2.25.so.sav
-rwxr-xr-x 1 root root 14950464 Apr 21 15:36 libc-2.25.so
-rwxr-xr-x 1 root root  1709880 Apr 21 15:03 libc-2.25.so.sav
-rwxr-xr-x 1 root root   567888 Apr 21 15:37 libthread_db-1.0.so
-rwxr-xr-x 1 root root    35624 Apr 21 15:04 libthread_db-1.0.so.sav

I had to boot to another lfs instance to be able to copy the files. It would not be a problem from the host and /mnt/lfs/lib, but if the user decides to do it after booting, it's a bit more complex. I don't know where we should put that discussion -- page, wiki, hint?

[DJ Lucas]

I think we should just do the list above as part of the existing stripping instructions. Don't even make it optional. If the users want to strip those libs, let them do so at their own risk. We would be doing exactly what the distros do already, but it's an opportunity to teach the why.

[bdubbs@…]

Added instructions at revision 11226 but leaving the ticket open for review.

[DJ Lucas]

Removed GCC libraries that are not installed in LFS. Completed in r11227.

[Armin]

My apologies for getting at this at this time, I wish I noticed this earlier.

There's something called "Separate debug info", which mainstream distros seem to employ to create so called debug packages (mostly suffixed -dbg or -debug). You strip the library installed in the filesystem, but copy its debug data to another file and package it separately.

The common practice I've seen is that such files are moved into /usr/lib/debug hierarchy, which is what gdb is searching for. Here's but one example on how to create separate debug information:

​https://github.com/elkrejzi/system-management/blob/master/buildscripts/master.sh#L182

[bdubbs@…]

Reopening. Thanks fo the pointer to objcopy. This looks like a better solution.

[bdubbs@…]

Fixed at revision 11230.