[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: install-strip variant that strips then installs?

From: Robert Boehne
Subject: Re: install-strip variant that strips then installs?
Date: Mon, 13 May 2013 05:55:55 -0500
User-agent: K-9 Mail for Android

Library paths are hard coded at link time.  For that reason, on some platforms 
Libtool relinks binaries during install.  Because "prefix" et. al. can be set 
at make time, stripping has to be done on the installed binary because it may 
not exist until then.

So strip before install would not be portable.


Robert Boehne

Gavin Smith <address@hidden> wrote:

>On Tue, May 7, 2013 at 5:12 PM, Rhys Ulerich <address@hidden>
>> I gather that 'make install-strip' installs and then strips binaries.
>> Is there some variant that reverses the order?  If not, any
>> recommendations for how to write one in an Automake-compliant manner?
>> My unstripped binaries are absurdly large and my installation
>> directory is NFS-mounted.  So I get to pay lots of network overhead
>> install what eventually becomes O(100MB) of binaries because the
>> unstripped copy is O(1.5GB).
>> Thanks,
>> Rhys
>This seems like a good idea to me. Is there any reason why the order
>couldn't be reversed?
>The only problem I can think of is that make install-strip isn't
>expected to modify the binaries in the build directory, and the user
>might conceivably be relying on them being unstripped (for some
>obscure reason). If that could be a problem, perhaps a solution is to
>have a separate "strip" rule which could be run.
>You could try writing a rule yourself in your to strip the
>binaries. You could use the bin_PROGRAMS make variable that is set in
>the output Makefile.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]