[Top][All Lists]

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

Re: automake 1.4g: About `make install-strip'

From: Maciej W. Rozycki
Subject: Re: automake 1.4g: About `make install-strip'
Date: Tue, 29 May 2001 11:56:05 +0200 (MET DST)

On 28 May 2001, Alexandre Oliva wrote:

> >  I was thinking of a configure-time check if `install -s' works.
> I'm not sure I'd trust such a check.  I'm pretty sure it might be
> possible to construct situations in strip would succeed in stripping a
> certain simple program for a different architecture, but would fail in
> case of more complex programs, for example, containing other sections.

 Well, the strip program from GNU binutils does check if it supports the
exact target, i.e. it is not enough for it to support e.g. "elf32-little"
to strip an "elf32-littlemips" binary.  Can't comment non-ELF BFDs,

> > For example I have $tooldir/bin first in the PATH environment
> > variable when doing cross-builds, so `install -s' succeeds for me.
> cross tools are generally named <target>-<progname>.  If install looks
> for `strip', it will find the wrong one.

$ ls -li /usr/bin/mipsel-linux-strip /usr/mipsel-linux/bin/strip
 126794 -rwxr-xr-x    2 root     root       217436 Feb  3 19:47
 126794 -rwxr-xr-x    2 root     root       217436 Feb  3 19:47

That's the standard way binutils get installed.

> > another possibility is to extend install so it can be instructed to
> > use a specific program to strip.  The install program is a part of
> > fileutils -- there should be no technical problem with making any
> > changes.
> Except that it wouldn't fix the immense installed user base of GNU

 Not immediately, of course.

> install, plus all other install programs, so we can't depend on this

 We already treat other GNU tools specially, e.g. ld.

> working anyway.  Of course, we can test for this feature before
> committing to it.  But I don't like adding configure-time tests that
> few people would use (I generally prefer to defer to `missing'), and
> then, we'd be running a shell-script anyway, and we wouldn't be able
> to cache results, unless we came up with some way for missing to cache
> results of tests.

 That's a valid argument.  Especially as there is still the
"INSTALL_PROGRAM='${INSTALL} -s'" alternative. 


+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail: address@hidden, PGP key available        +

reply via email to

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