Discussion:
[gentoo-portage-dev] Avoid stripping ld.so ?
Joakim Tjernlund
2018-08-29 20:10:54 UTC
Permalink
Is there a way for portage to avoid strippning debug syms for ld.so ?
I would like to avoid building all of glibc
Sergei Trofimovich
2018-08-29 22:58:38 UTC
Permalink
On Wed, 29 Aug 2018 20:10:54 +0000
Post by Joakim Tjernlund
Is there a way for portage to avoid strippning debug syms for ld.so ?
Tweaking ebuild to expand STRIP_MASK for ld.so might help.
Post by Joakim Tjernlund
I would like to avoid building all of glibc with debug syms.
s/building/installing, right?

You will have to build all (or large part) of glibc with debug
symbols anyways as ld.so is linked of multiple source files.
--
Sergei
Joakim Tjernlund
2018-08-30 07:15:24 UTC
Permalink
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Wed, 29 Aug 2018 20:10:54 +0000
Post by Joakim Tjernlund
Is there a way for portage to avoid strippning debug syms for ld.so ?
Tweaking ebuild to expand STRIP_MASK for ld.so might help.
OK, can I use STRIP_MASK outside ebuilds, like in /etc/portage/make.conf or
in my profile? Something like STRIP_MASK="/lib64/ld-* /lib/ld-*"
Post by Joakim Tjernlund
I would like to avoid building all of glibc with debug syms.
s/building/installing, right?
Right :) I need to keep the stuff valgrind need. Don't recall if that
just needs an unstripped ld.so or if ld.so needs debug syms as well.
You will have to build all (or large part) of glibc with debug
symbols anyways as ld.so is linked of multiple source files.
Yes, I just need to build glibc with -g and avoid stripping ld.so

I think this should be default/USE flag for glibc, it would be a
nice feature so one does not need to rebuild glibc(and extra space)
run valgrind.
--
Joakim Tjernlund
2018-08-30 07:37:16 UTC
Permalink
Post by Joakim Tjernlund
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Wed, 29 Aug 2018 20:10:54 +0000
Post by Joakim Tjernlund
Is there a way for portage to avoid strippning debug syms for ld.so ?
Tweaking ebuild to expand STRIP_MASK for ld.so might help.
OK, can I use STRIP_MASK outside ebuilds, like in /etc/portage/make.conf or
in my profile? Something like STRIP_MASK="/lib64/ld-* /lib/ld-*"
Post by Joakim Tjernlund
I would like to avoid building all of glibc with debug syms.
s/building/installing, right?
Right :) I need to keep the stuff valgrind need. Don't recall if that
just needs an unstripped ld.so or if ld.so needs debug syms as well.
You will have to build all (or large part) of glibc with debug
symbols anyways as ld.so is linked of multiple source files.
Yes, I just need to build glibc with -g and avoid stripping ld.so
I think this should be default/USE flag for glibc, it would be a
nice feature so one does not need to rebuild glibc(and extra space)
run valgrind.
Arch seems to keep syms too:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/glibc#n178
# Do not strip these for gdb and valgrind functionality, but strip the rest
find "$pkgdir"/usr/lib \
-not -name 'ld-*.so' \
-not -name 'libc-*.so' \
-not -name 'libpthread-*.so' \
-not -name 'libthread_db-*.so' \
-name '*-*.so' -type f -exec strip
Sergei Trofimovich
2018-08-30 19:12:15 UTC
Permalink
On Thu, 30 Aug 2018 07:37:16 +0000
Post by Joakim Tjernlund
Post by Sergei Trofimovich
Tweaking ebuild to expand STRIP_MASK for ld.so might help.
OK, can I use STRIP_MASK outside ebuilds, like in /etc/portage/make.conf or
in my profile? Something like STRIP_MASK="/lib64/ld-* /lib/ld-*"
I believe you can't. You would have to resort to /etc/portage/bashrc
hacks to override ebuilds' value. Requesting new feature from dev-portage@
sounds reasonable.

For example, add STRIP_MASK_USER to be controlled by user.

STRIP_MASK is normally used for cases when software breaks when
stripped (examples: not-quite-ELF files, not-yet-linked .o files). Not
something for convenience or niche purposes.

STRIP_MASK_USER might be a good way to fine-grain desired policy
of stripping package on top of existing FEATURES=nostrip knob.
--
Sergei
Joakim Tjernlund
2018-08-31 06:56:50 UTC
Permalink
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Thu, 30 Aug 2018 07:37:16 +0000
Post by Joakim Tjernlund
Post by Sergei Trofimovich
Tweaking ebuild to expand STRIP_MASK for ld.so might help.
OK, can I use STRIP_MASK outside ebuilds, like in /etc/portage/make.conf or
in my profile? Something like STRIP_MASK="/lib64/ld-* /lib/ld-*"
I believe you can't. You would have to resort to /etc/portage/bashrc
sounds reasonable.
For example, add STRIP_MASK_USER to be controlled by user.
STRIP_MASK is normally used for cases when software breaks when
stripped (examples: not-quite-ELF files, not-yet-linked .o files). Not
something for convenience or niche purposes.
STRIP_MASK_USER might be a good way to fine-grain desired policy
of stripping package on top of existing FEATURES=nostrip knob.
Yes, I like this idea with STRIP_MASK_USER

Jock

Zac Medico
2018-08-30 20:01:07 UTC
Permalink
Post by Joakim Tjernlund
Is there a way for portage to avoid strippning debug syms for ld.so ?
I would like to avoid building all of glibc with debug syms.
Maybe use FEATURES=splitdebug together with INSTALL_MASK="/usr/lib/debug
-ld-*.so.debug"?
--
Thanks,
Zac
Joakim Tjernlund
2018-08-31 06:55:11 UTC
Permalink
Post by Zac Medico
Post by Joakim Tjernlund
Is there a way for portage to avoid strippning debug syms for ld.so ?
I would like to avoid building all of glibc with debug syms.
Maybe use FEATURES=splitdebug together with INSTALL_MASK="/usr/lib/debug
-ld-*.so.debug"?
That could work, but is somewhat hacky.
One also need to apply the *MASK only for glibc so you don't mess with other pkgs
and I need to do this from a custom profile where I have to apply such things
from within bashrc hacks as I cannot make package.env work there, or did I miss something?

If not, could portage profile handling
Loading...