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,
though.
> > 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
/usr/bin/mipsel-linux-strip
126794 -rwxr-xr-x 2 root root 217436 Feb 3 19:47
/usr/mipsel-linux/bin/strip
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
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [EMAIL PROTECTED], PGP key available +
