Re: Upgrading autoconf

[Eric Fowler]

Gee ,thanks.

Everything is fine now but I am still unaccountably picking up the old
version from /usr/bin.

Check this out:

address@hidden ~]$ echo $PATH
/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/eric/bin

## OK, the path looks fine ..

address@hidden ~]$ autoconf --version
autoconf (GNU Autoconf) 2.59
##That's the old version, I want 2.61

address@hidden ~]$ which autoconf
/usr/local/bin/autoconf
## Just as I expect, I just ./config && make && make install 'ed in there.
Let's look closer at that version:

address@hidden ~]$ /usr/local/bin/autoconf --version
autoconf (GNU Autoconf) 2.61
## WHAAAT?!? That's the version I want .. but according to my path I should
be getting it when I run without the fully qual'd name

address@hidden ~]$  ls -la /usr/local/bin/autoconf
-rwxr-xr-x 1 root root 13415 Oct  1 20:46 /usr/local/bin/autoconf
##OK, that's the one I just now made, no problem ... let's see if there is
one in Kerberos muddying the waters:

address@hidden ~]$  ls /usr/kerberos/autoconf
ls: /usr/kerberos/autoconf: No such file or directory
## Nope. No surprise, just checking.

address@hidden ~]$ ls -la /usr/bin/autoconf
-rwxr-xr-x 1 root root 7663 Oct 13  2006 /usr/bin/autoconf
##Hmm, that one looks old - let's just check:

address@hidden ~]$ /usr/bin/autoconf --version
autoconf (GNU Autoconf) 2.59

##Sho 'nuff!

##So why am I getting the older version from 'downstream' on the $PATH, and
not that 2.61 version from /usr/local??

##It would be easy to lead-pipe this by deleting that one file from /usr/bin
but that is cheating. ##Why is this happening??

Thanks

Eric




On 10/1/07, Bob Proulx <address@hidden> wrote:
>
> Eric Fowler wrote:
> > I have the tarball for autoconf.2.61.tar.gz .
> >
> > Now what the @#! do I do with it?
>
> Okay.  The first thing to do is to light up an aroma therapy candle
> and then silently meditate to harness your inner Qi.  :-)
>
> > I know I can unzip and untar it but in
> > which directory does it "want" to reside?
>
> It wants to reside in whatever working directory you want to use to
> work with the source code.  This is not the installation location.  I
> personally use ~/src/ (aka $HOME/src/) for my work area but this can
> just as easily be done in /tmp if it is truly temporary.  (Many
> systems are configured to purge /tmp on reboot so don't keep anything
> you want to keep there.  After a reboot it would be gone, gone, gone.)
>
> > I unzip'ed it into /tmp and ran ./configure && make && make install
>
> Sounds good.  If you did that then stop.  You are done.  You have
> already installed it with the 'make install' part.
>
> > and got a tree built under tmp which is not where I want it.
>
> The tree in /tmp/autoconf-2.61 is the source code used to build and
> install but is not the installation image.  You can remove it after
> you have installed it.  I tend to keep the program around so that I
> can use it to 'make uninstall' to remove it after I no longer need it
> or before upgrading to the next version which may install differently
> named files.  Removing the old version cleans up the lint from the
> system.
>
> > Where to put it and how exactly to unzip?
>
> You already did it.  But the instructions are in the INSTALL file
> included in the distribution after you unpack the tar archive.
>
>     Briefly, the shell commands `./configure; make; make install'
>     should configure, build, and install this package.
>
> The default installation location is /usr/local.  If you did exactly
> what was said there then you have installed autoconf into /usr/local
> and the program will be located in /usr/local/bin/autoconf along with
> others in the package.
>
> Since /usr/local/bin is normally in PATH ahead of /usr/bin any files
> placed there will be run instead of the system installed version.
> Installing into /usr/local overrides /usr/bin.  Here is a typical user
> PATH.
>
>   PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
>
> One useful command would be to run 'make check' to have autoconf run
> all of the tests in the test suite.  This may take quite a while but
> would be a good thing to do to verify that it is running correctly.
> This tests the working copy (in /tmp or wherever) and not the
> installed copy because it is usually run as a check and then when that
> is verified good the package is installed.
>
> Bob
>