Hi,
someone at the computing center just told me that the version of "install"
that caused the problem was terribly obsolete and only got installed by
accident. It has been removed now.
If you want to add an autoconf check for this version, I can try to get
a copy of the binary. But I'm not sure
On Thu, Nov 03, 2005 at 10:25:28AM -0800, James E Wilson wrote:
> On Wed, 2005-11-02 at 02:35, Martin Reinecke wrote:
> > Unfortunately I have no way of finding out more about the local "install",
> > as it doesn't accept the --help flag:
>
> Did you check to see if it might be a shell script? If
On Wed, 2005-11-02 at 02:35, Martin Reinecke wrote:
> Unfortunately I have no way of finding out more about the local "install",
> as it doesn't accept the --help flag:
Did you check to see if it might be a shell script? If so, there might
be comments in it. If it isn't a shell script, then runn
On Nov 2, 2005, at 2:35 AM, Martin Reinecke wrote:
Is this a bug in my local version of "install", or could it be
interpreted as acceptable behaviour?
I'd call it a bug. Free free to recraft your environment to not
feature that install. If it were a popular install, a check for it
could
Hi Jim,
the problem lies in the command
-$(INSTALL_PROGRAM) xgcc$(exeext)
$(DESTDIR)$(bindir)/$(GCC_INSTALL_NAME)$(exeext)
which on my machine evaluates to
/afs/rzg/@sys/bin/install -c xgcc /afs/mpa/data/martin/ugcc/bin/gcc
Apparently this special version of "install" in my path crea
Jim Wilson wrote:
Martin Reinecke wrote:
i.e. the "gcc" binary ends up as "xgcc" in a subdirectory called "gcc".
The gcc makefile install rule just does
rm -f $destdir/bin/gcc
install xgcc $destdir/bin/gcc
If destdir/bin/gcc is non-existant, or a plain file, then this works as
expected.
Martin Reinecke wrote:
i.e. the "gcc" binary ends up as "xgcc" in a subdirectory called "gcc".
The gcc makefile install rule just does
rm -f $destdir/bin/gcc
install xgcc $destdir/bin/gcc
If destdir/bin/gcc is non-existant, or a plain file, then this works as
expected. If destdir/bin/gcc
