[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_TYPE_SIZE_T
AC_TYPE_OFF_T
-AC_PREFIX_PROGRAM(gzip)
-
AC_CONFIG_FILES([Makefile doc/Makefile lib/Makefile])
AC_OUTPUT
--
1.6.5.1.281.g7c7f7