bug-gzip
[Top][All Lists]
Advanced

[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: Wed, 14 Oct 2009 22:31:28 +0200

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.




reply via email to

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