Re: [gentoo-portage-dev] Avoid stripping ld.so ?

2018-08-31 Thread Joakim Tjernlund
On Thu, 2018-08-30 at 20:12 +0100, Sergei Trofimovich wrote:
> 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 +
> Joakim Tjernlund  wrote:
> 
> > > > 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.

Yes, I like this idea with STRIP_MASK_USER

 Jocke


Re: [gentoo-portage-dev] Avoid stripping ld.so ?

2018-08-30 Thread Zac Medico
On 08/29/2018 01:10 PM, Joakim Tjernlund wrote:
> 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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] Avoid stripping ld.so ?

2018-08-30 Thread Sergei Trofimovich
On Thu, 30 Aug 2018 07:37:16 +
Joakim Tjernlund  wrote:

> > > 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



Re: [gentoo-portage-dev] Avoid stripping ld.so ?

2018-08-30 Thread Joakim Tjernlund
On Thu, 2018-08-30 at 09:15 +0200, Joakim Tjernlund wrote:
> On Wed, 2018-08-29 at 23:58 +0100, Sergei Trofimovich wrote:
> > 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 +
> > Joakim Tjernlund  wrote:
> > 
> > > 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-*"
> 
> > 
> > > 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 $STRIP_SHARED {} + 2> /dev/null || true




Re: [gentoo-portage-dev] Avoid stripping ld.so ?

2018-08-30 Thread Joakim Tjernlund
On Wed, 2018-08-29 at 23:58 +0100, Sergei Trofimovich wrote:
> 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 +
> Joakim Tjernlund  wrote:
> 
> > 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-*"

> 
> > 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.

> 
> --
> 
>   Sergei



Re: [gentoo-portage-dev] Avoid stripping ld.so ?

2018-08-29 Thread Sergei Trofimovich
On Wed, 29 Aug 2018 20:10:54 +
Joakim Tjernlund  wrote:

> 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.

> 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