Stripping of binaries (Was: Re: svn commit: r350052 - head/Mk)

[Baptiste Daroussin]

On Fri, Apr 04, 2014 at 08:58:11AM +0000, Alexey Dokuchaev wrote:
> On Thu, Apr 03, 2014 at 10:11:52PM +0000, Baptiste Daroussin wrote:
> > New Revision: 350052
> > URL: http://svnweb.freebsd.org/changeset/ports/350052
> > QAT: https://qat.redports.org/buildarchive/r350052/
> > 
> > Log:
> >   Prepend install(1) command with the STRIPBIN env defined to the proper
> >   STRIPBIN to allow cross-installation
> 
> I think it's good time to rethink our stripping policy/strategy at large, as
> it is kind of mess overall, and now I see the risk of it to become even more
> messy with introduction of cross-building.
> 
> So, we have ports with their own `do-install' targets, and binaries are
> normally installed with INSTALL_(PROGRAM|LIB), which includes `-s' switch by
> default; passing STRIPBIN via env allows install(1) to call correct strip(1)
> in cross-case, right?
> 
> Other ports deploy files through a vendor's routine, which can be anything,
> from install(1) to cp(1) or tar(1) or cpio(1).  Some of them try to strip
> binaries during compilation; others do it on install, or may not do at all.
> 
> I've recently started to notice that folks strip binaries in `post-install'
> target.  Frankly, I don't understand 1) why it is being done this way, and
> 2) why it become so popular.  It is not just ugly on its own, it is ugly on
> a much larger scale as it adds little, almost identical, imperative pieces
> of code to *a lot* of Makefiles.  What makes me wonder even more, this is
> being done for staged ports!
> 
> I propose that, instead of adding hacks for `-s' feature of install(1) we
> remove this switch completely from INSTALL_* knobs, and remove any manual
> STRIP_CMD's from ports' Makefile.  Let the files in $STAGEDIR be unstripped,
> there is nothing wrong with it; moreover, staging allows precisely for any
> pre-package tuning, file cherry-picking, etc.
> 
> Stripping should be done by pkg(8) when generating final package (perhaps
> subject to some NO_STRIP/NO_STRIP_FILES knob or something).  This will also
> ensure that correct strip(1) binary will be called, without exposing it to
> install(1).  It will also allow to consolidate stripping logic in one place
> instead of having it scattered around the whole Ports Tree.
> 
> Makefiles should stay mostly declarative.  Adding code there just does not
> look right upfront.
> 
While I do agree with the problem you are spotting the solution is imho not the
one you propose at all.

To have a clean solution we have to get a long term view about the package
building.

Here are the list of problems we have with stripping.
- .a are often installed in the stage in 444 mode, meaning you cannot strip them
  as a simple user after staging
- cross building involves a different strip binary
- in very long term we want to be able to extract the debug flags in the stage
  dir to be able to create some debug packages.
- some badly written program/libraries only works when not stripped so we need a
  way to declares (don't strip this)


In my opinion stripping should not be done my pkg register/create at all but
should be done globally by the ports framework, but having this done properly
and safely (fixing all the above listed problem) would need changing lot of
things in bsd.port.mk and fixing lot of logic which cannot easily be done
without a risk to break something

Generally speaking the ports tree needs to grow up with more and more automated
concept like compressing manpages, stripping binaries, (compressing docs?),
generating .py* (for python) and so one.

Right now we have no clean framework to instrument that compress-man is a first
step but I will hate to add new target in a non automated way to implement that.

That said, if someone want to step up and write a "post-stage" framework to
easily plug new automated operation could then properly handle properly.

I'm 100% pro-declarative only makefile :)

regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-ports-all/attachments/20140404/71a8e604/attachment-0001.sig>