[GRASS5] [bug #3033] (grass) Makefile has trouble with

[Glynn Clements]

Request Tracker wrote:

> this bug's URL: http://intevation.de/rt/webrt?serial_num=3033

> Subject: Makefile has trouble with 
> Platform: Solaris2.X/Sparc
> grass obtained from: Trento Italy site
> grass binary for platform: Compiled from Sources
> GRASS Version: 6.00beta1,2

> Grass6 doesn't compile on my solaris 8 system. There are a few
> survivable errors, but the biggest problem is that the makefiles call
> "install" which doesn't behave as it seems the makefile expects it to
> (or indeed as the man page expects it to). In various places in the
> makefile, you get commands like this:
> 
> $(INSTALL) -m [123] [somefilename] [somedirname]/
> 
> This is *supposed* to do the following:
> execute a "find" command on [somedirname]/[somefilename]
> If file exists, issue a warning and overwrite
> If file doesn't exist, just install.
> What it actually does is:
> If file exists, just install
> If file does not exist, puke your guts out and die.

Then "install" is broken.

The AC_PROG_INSTALL macro used by the configure script should set the
INSTALL variable to the path to the supplied install-sh script if it
fails to detect a usable install program.

However, include/Make/Platform.make.in unconditionally defines:

	INSTALL             = install

It should be:

	INSTALL             = @INSTALL@

so that the install-sh script will be used when appropriate.

Even so, it isn't certain that configure will always detect when the
system's install program is broken.

> Apparently "find" which is called by "install" doesn't like not
> finding the file (even though this is expected) so it exits
> abnormally, causing "install" to do the same. Also, there are some
> instances of:
> 
> $(INSTALL) -m [123] *.* [somedirname]/
> or
> $(INSTALL) -m [123] [somefilename] [somedirname]/[someotherfilename]
> 
> Apparently my version of install doesn't take wildcards, and doesn't
> like giving the installed file a different name than the original
> file.

The install program doesn't need to take wildcards; these are expanded
by the shell. It's possible that install doesn't like multiple
filenames.

> It seems to me that "install" doesn't do anything, really, that "cp
> -f" wouldn't do. Am I wrong about this?

Yes. If the destination exists, "cp" will open the existing file for
writing then overwrite its contents, whereas "install" should create a
new file in the same directory then rename it over the existing file.

The difference is significant for two main reasons:

1. If the destination is an executable or shared library which is
currently in use by some process, the "cp" behaviour will do the wrong
thing (for an executable, open() will fail with ETXTBSY; for a shared
library, any processes which were using it may crash).

2. If there are additional hard links to the destination, "cp" will
modify the file (inode) to which all links refer. "install" will make
the specified link (filename) refer to the new file; all other links
will refer to the old file, which will remain unchanged.

> Where is $(INSTALL) set to /sbin/install so I can change it?

In include/Make/Platform.make.in; try using @INSTALL@ instead, as
mentioned above. If configure doesn't decide to use the install-sh
script, change include/Make/Platform.make manually after configure has
finished.

> Perhaps some change needs to be made to the makefiles to make them a
> bit more robust on solaris. Or maybe I need to find newer versions of
> "find" and "install"... but where?

We need to fix Platform.make.in to use @INSTALL at . In cases where that
doesn't work (i.e. where configure fails to detect that we need to use
the install-sh script), it should suffice to use:

	make INSTALL="`pwd`/install-sh"

to force the use of the script.

-- 
Glynn Clements <glynn at gclements.plus.com>