Details Ticket 3033


Comment | Reply | Take | Open


Serial Number 3033
Subject Solaris: Makefile has trouble with 'install'
Area grass5.7
Queue grass
Requestors gwurman@asu.edu
Owner none
Status resolved
Last User Contact Tue Jul 19 23:39:23 2005 (3 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Sun Jul 2 22:03:26 2006 (2 yr ago)
Created Fri Feb 25 23:27:00 2005 (4 yr ago)

Transaction History Ticket 3033


Fri, Feb 25 2005 23:27:00    Request created by guest  
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

Hey folks,

This is somewhat of a followup to my previous whiney thread, but it's well defined
enough that I thought it should go by itself.  Enough preamble.

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.

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.  My workaround for
this has been to add to each makefile a hackneyed series of foreach loops, touch
commands and mv commands to rename files at the end, but there has to be a better
way around this.

It seems to me that "install" doesn't do anything, really, that "cp -f" wouldn't
do.  Am I wrong about this?  Where is $(INSTALL) set to /sbin/install so I can
change it?

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?

Thanks for any help,
Gilead Wurman
ASU Active Tectonics
Sun, Feb 27 2005 23:53:49    Subject changed to Solaris: Makefile has trouble with 'install' by hbowman  
Mon, Feb 28 2005 13:03:40    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <16931.2193.712039.428321@gargle.gargle.HOWL>
Date Mon, 28 Feb 2005 12:03:29 +0000
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3033] (grass) Makefile has trouble with
In-Reply-To <20050225222700.CC3AA102C00@lists.intevation.de>
References <20050225222700.CC3AA102C00@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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@. 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@gclements.plus.com>


Wed, Mar 2 2005 20:37:29    Mail sent by guest  
OK, setting INSTALL = @INSTALL@ in Platform.make.in seems to have done the
trick!  Thanks a lot.

One small (non-critical) error I get is in d.extend.  I don't need this for
what I'm doing, I just thought I should report it:

d.extend
make[2]: Entering directory
`/export/home/gwurman/Codes/grass-6.0.0beta2/display/d.extend'
gcc -I/export/home/gwurman/Codes/grass-6.0.0beta2/include
-I/export/home/gwurman/Codes/grass-6.0.0beta2/dist.sparc-sun-solaris2.8/include/grass
-w -g -Wall  -Wall -Wconversion -Wno-implicit-int      
-DPACKAGE=\""grassmods"\" 
-I/export/home/gwurman/Codes/grass-6.0.0beta2/include
-I/export/home/gwurman/Codes/grass-6.0.0beta2/dist.sparc-sun-solaris2.8/include/grass
\
	-o OBJ.sparc-sun-solaris2.8/main.o -c main.c
In file included from
/export/home/gwurman/Codes/grass-6.0.0beta2/include/vect/digit.h:3,
                 from
/export/home/gwurman/Codes/grass-6.0.0beta2/include/Vect.h:4,
                 from main.c:17:
/export/home/gwurman/Codes/grass-6.0.0beta2/include/vect/dig_structs.h:22:21:
ogr_api.h: No such file or directory
In file included from
/export/home/gwurman/Codes/grass-6.0.0beta2/include/vect/digit.h:3,
                 from
/export/home/gwurman/Codes/grass-6.0.0beta2/include/Vect.h:4,
                 from main.c:17:
/export/home/gwurman/Codes/grass-6.0.0beta2/include/vect/dig_structs.h:170:
error: parse error before "OGRDataSourceH"
/export/home/gwurman/Codes/grass-6.0.0beta2/include/vect/dig_structs.h:186:
error: parse error before "feature_cache"
/export/home/gwurman/Codes/grass-6.0.0beta2/include/vect/dig_structs.h:209:
error: parse error before '}' token
/export/home/gwurman/Codes/grass-6.0.0beta2/include/vect/dig_structs.h:213:
error: field `ogr' has incomplete type
make[2]: *** [OBJ.sparc-sun-solaris2.8/main.o] Error 1
make[2]: Leaving directory
`/export/home/gwurman/Codes/grass-6.0.0beta2/display/d.extend'

Thanks for the help!

Gilead Wurman
ASU Active Tectonics
Tue, Jul 19 2005 23:39:23    Mail sent by mneteler  
Hi,

can you please test again with a current 6.1-CVS snapshot?
We have made lot's of fixes for compilers.

Markus
Wed, Jul 20 2005 00:04:17    Mail sent by gwurman@asu.edu  
Return-Path <gwurman@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
Mime-Version 1.0 (Apple Message framework v619.2)
In-Reply-To <20050719213923.9BF391006CC@lists.intevation.de>
References <20050719213923.9BF391006CC@lists.intevation.de>
Content-Type text/plain; charset=US-ASCII; format=flowed
Message-Id <bb32f7bea95741715e0f5c431cf173be@asu.edu>
Content-Transfer-Encoding 7bit
From Gilead Wurman <gwurman@asu.edu>
Subject Re: [bug #3033] (grass) Solaris: Makefile has trouble with 'install'
Date Tue, 19 Jul 2005 15:04:14 -0700
To Markus Neteler via RT <grass-bugs@intevation.de>
X-Mailer Apple Mail (2.619.2)
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
I actually recompiled yesterday from CVS with no errors.  I had totally 
forgotten about this :-)

Gilead Wurman
ASU Active Tectonics


Sat, Jul 23 2005 14:43:33    Status changed to resolved by msieczka  
Sun, Jul 2 2006 22:03:26    Comments added by guest  
Test
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request