[Top][All Lists]

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

Re: default prefix not honored, gzip 1.3.13, possibly before?

From: Jim Meyering
Subject: Re: default prefix not honored, gzip 1.3.13, possibly before?
Date: Tue, 20 Oct 2009 13:24:12 +0200

Jim Meyering wrote:

> Zube wrote:
>> A newly installed CentOS 5.3 x86_64 machine, with a mostly unpopulated
>> /usr/local.  gzip has never been installed under /usr/local, the
>> only gzip that exists is the local system one (/usr/bin/gzip, a link
>> to /bin/gzip).
>> I run:
>> ./configure
>> gmake
>> gmake install
>> and it drops the install in /usr/bin.  Starting on line 19611 of the
>> configure script, the prefix is changed based on where gzip is
>> currently installed.  This is surprising and annoying behavior.
>> The configure script is explicit:
>> ./configure --help
>> ***
>> Installation directories:
>>   --prefix=PREFIX         install architecture-independent files in PREFIX
>>                           [/usr/local]
>> By default, `make install' will install all the files in
>> `/usr/local/bin', `/usr/local/lib' etc.
>> ***
>> Thanks to this errant behavior (off the top of my head, I know of no
>> other GNU program that does this), I'm going to have a bit of manual
>> undo to do.  I can force the build to do what I want with:
>> ./configure --prefix=/usr/local
>> but dear me, I shouldn't have to.
>> Could you please either document this behavior and change the output of
>> ./configure --help or remove the check completely?  It makes no sense
>> to change the default install location based on where gzip is found.
> Thanks for the report.
> That is indeed surprising, and IMHO undesirable.
> However, the logs suggest that gzip's installation process has been
> working that way (using AC_PREFIX_PROGRAM(gzip), now in configure.ac)
> for more than 10 years, so removing that "feature" would probably cause
> more harm than good.
> The only alternative I can imagine would be to make configure
> fail if --prefix=/something is not specified.  And I'm sure some
> would object to that, too.  So maybe the status quo is best.

On second thought (and upon a prod from Karl Berry, thanks ;-),
I've gone ahead and made the change after all.
The existing behavior is just too non-intuitive.

>From 7ef3730c1f88b398d9633eed877a81d46bc5f16b Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Tue, 20 Oct 2009 13:21:21 +0200
Subject: [PATCH] build: do not use AC_PREFIX_PROGRAM

* configure.ac: Do not use "AC_PREFIX_PROGRAM(gzip)".
It would induce behavior that is so surprising that it is probably
universally considered to be buggy, these days.  Reported by Zube
in http://thread.gmane.org/gmane.comp.gnu.gzip.bugs/273
 configure.ac |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 174a59e..c568c02 100644
--- a/configure.ac
+++ b/configure.ac
@@ -109,7 +109,5 @@ AC_TYPE_SIGNAL

 AC_CONFIG_FILES([Makefile doc/Makefile lib/Makefile])

reply via email to

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