How to Configure/Make/Install Against an Older Version of a Library

How do I configure/make/install against an older version of a library?

Clearly, you have to obtain, compile and install the older version of ImageMagick.

Faced with this problem - especially since it is at an experimental phase (you don't know for sure you want to keep this version of ImageMagick around) - I would:

Create a new directory to install ImageMagick:
```
/opt/ImageMagick
```
Configure ImageMagick 6.3.9 to install in there - probably:
```
./configure --prefix=/opt/ImageMagick
```
Build, test, and install it.

Configure moddims to look in the ImageMagick location before standard places:

export LDFLAGS=-L/opt/ImageMagick/lib
export CPPFLAGS=-I/opt/ImageMagick/include
./configure ....

Check that the produced moddims code uses your preferred libraries:

otool -L ...moddims-progam-or-library...    # MacOS X
ldd ...moddims-program-or-library...        # Linux, etc.

The first check will be "does moddims compile when configured"; if it doesn't, you are probably using the 'standard' version of the moddims header file despite this attempt to avoid doing so.

There might also be configure options to specify where the ImageMagick library should be pulled from - check with './configure --help' (and/or 'grep -i image configure').

Unable to Install Older Version of R

Please try the following steps:

First make sure if you have libxt-dev and jdk.

dpkg -l <package name>

If not do these following commands:

sudo apt -f install && sudo apt update && sudo apt dist-upgrade
sudo apt-get install build-essential
sudo apt-get install fort77
sudo apt-get install xorg-dev
sudo apt-get install liblzma-dev  libblas-dev gfortran
sudo apt-get install gcc-multilib
sudo apt-get install gobjc++
sudo apt-get install aptitude
sudo aptitude install libreadline-dev
sudo apt-get install libxt-dev
sudo apt-get install default-jdk

Then download your preferred R version and do as follows:

wget https://cran.r-project.org/src/base/R-3/R-3.2.1.tar.gz
mkdir R-3.2.1
mv R-3.2.1.tar.gz R-3.2.1/
cd R-3.2.1/
tar -xzvf R-3.2.1.tar.gz

Next, make another folder for R's binary version and use the to that folder here:

mkdir <full path>/R3.2.1_VERSION

Build R from source, please make sure to add the full path in prefix

./configure --prefix=<full path>/R3.2.1_OLDERVERSION --enable-R-shlib --with-blas --with-lapack
make
sudo make install

Once, you are finished, please set the environment variable to make sure the right version of R is called

export PATH=<full path>/R3.2.1_VERSION/bin:$PATH

If everything went smoothly then you can see your current R version as 3.2.1 when you run R.
If you want to switch to another version of R then change the environment variable to your preferred version of R package in your account as follows:

export PATH=<full path>/R<your preferred>_VERSION/bin:$PATH

how to configure apps to use older version of library by default

Installl everything you build from sources to /usr/local, as per the default prefix of configure.

Update: if you plan to distribute this package further, then a different approach is needed. I would create a directory named say /usr/lib/future and place an advanced version of libpoppler.so there. The application would link against it, using the -rpath=/usr/lib/future and possibly -rpath-link=/usr/lib/future.

How to build a './configure && make && make install' software against a custom library which I also build?

You built against a library, but the system doesn't know where the library is. Since you don't want to install the library, but rather leave it in the place where you built it, you could solve it with -rpath= option of the linker — it embeds a search path for libraries into the executable file.

Just rebuild your application with it being added to your LDFLAGS, like LDFLAGS="-rpath=/home/mypath/to/libevent" (but note, it is a linker option, and it is possible that in the makefile as a linker used the gcc itself — gcc does not know the option, then you need to write it likeLDFLAGS="-Wl,-rpath=/home/mypath/to/libevent" to force gcc to pass the option down to the actual linker)

By the way, actually you can change rpath even without recompiling the application — there's a tool patchelf for that job.

Installing older version of R package

To install an older version of a package from source (within R):

packageurl <- "http://cran.r-project.org/src/contrib/Archive/ggplot2/ggplot2_0.9.1.tar.gz"
install.packages(packageurl, repos=NULL, type="source")

If this doesn't work for you and you're on Windows, the reason is probably the lack of an appropriate tool chain for building/compiling packages. Normally you would install a pre-compiled binary from CRAN but they only archive package sources, not binaries.^[1] This means you need to install Rtools so that you can compile everything locally. (Note: Rtools is not an R package.)

@shadow's answer below also makes the case that you can use devtools::install_version(). That's also a good idea, but is also subject to needing Rtools on Windows.

As of September 18, 2015, a new package versions has appeared on CRAN. This relies on the Revolution Analytics MRAN server to install packages for specific versions or dates:

# install yesterday's version of checkpoint, by date
install.dates('checkpoint', Sys.Date() - 1)

# install earlier versions of checkpoint and devtools
install.versions(c('checkpoint', 'devtools'), c('0.3.3', '1.6.1'))

That has the advantage of not requiring Rtools to install binary packages on Windows, but only works going back to 2014-09-17 (when MRAN was launched).

To install an older version from the command line (outside of R):

You can also install a package by using R CMD INSTALL on the command line (Terminal, Command Prompt, etc.) once you have the package source ("tarball") locally on your machine, for example using wget (if you have it):

wget http://cran.r-project.org/src/contrib/Archive/ggplot2/ggplot2_0.9.1.tar.gz

or, if you're on Windows, an equivalent using PowerShell would be:

(new-object System.Net.WebClient).DownloadFile("http://cran.r-project.org/src/contrib/Archive/ggplot2/ggplot2_0.9.1.tar.gz", "./ggplot2_0.9.1.tar.gz")

or you can just download the source from the CRAN archive via your web browser.

To install from the local file, you can just do:

R CMD INSTALL ggplot2_0.9.1.tar.gz

That should work on any platform (with the same caveat - as above - about needing a tool chain for building packages).

^[1]_{This is no longer entirely true. From March 2016, CRAN has started hosting a "CRAN Archive" server that contains Windows and Mac binaries for very old versions of R (> 5 years old). You can now install directly from this server using install.packages(). See new R FAQ 7.44 for some details.}

How can I link to an older version of a shared library

You can use this syntax to link to a specific version of a library:


gcc [other options] -l:libtiff.so.4

You do not need to specify a path; the usual directories are searched in order to find the library.

Note: as Michael Wild mentioned, you should have the header files for that version installed instead of the newest ones.

Homebrew install specific version of formula?

TLDR: brew install postgresql@8.4.4 See answer below for more details.

*(I’ve re-edited my answer to give a more thorough workflow for installing/using older software versions with homebrew. Feel free to add a note if you found the old version better.)

Let’s start with the simplest case:

1) Check, whether the version is already installed (but not activated)

When homebrew installs a new formula, it puts it in a versioned directory like /usr/local/Cellar/postgresql/9.3.1. Only symbolic links to this folder are then installed globally. In principle, this makes it pretty easy to switch between two installed versions. (*)

If you have been using homebrew for longer and never removed older versions (using, for example brew cleanup), chances are that some older version of your program may still be around. If you want to simply activate that previous version, brew switch is the easiest way to do this.

Check with brew info postgresql (or brew switch postgresql <TAB>) whether the older version is installed:

$ brew info postgresql
postgresql: stable 9.3.2 (bottled)
http://www.postgresql.org/
Conflicts with: postgres-xc
/usr/local/Cellar/postgresql/9.1.5 (2755 files, 37M)
  Built from source
/usr/local/Cellar/postgresql/9.3.2 (2924 files, 39M) *
  Poured from bottle
From: https://github.com/Homebrew/homebrew/commits/master/Library/Formula/postgresql.rb
# … and some more

We see that some older version is already installed. We may activate it using brew switch:

$ brew switch postgresql 9.1.5
Cleaning /usr/local/Cellar/postgresql/9.1.5
Cleaning /usr/local/Cellar/postgresql/9.3.2
384 links created for /usr/local/Cellar/postgresql/9.1.5

Let’s double-check what is activated:

$ brew info postgresql
postgresql: stable 9.3.2 (bottled)
http://www.postgresql.org/
Conflicts with: postgres-xc
/usr/local/Cellar/postgresql/9.1.5 (2755 files, 37M) *
  Built from source
/usr/local/Cellar/postgresql/9.3.2 (2924 files, 39M)
  Poured from bottle
From: https://github.com/Homebrew/homebrew/commits/master/Library/Formula/postgresql.rb
# … and some more

Note that the star * has moved to the newly activated version

(*) Please note that brew switch only works as long as all dependencies of the older version are still around. In some cases, a rebuild of the older version may become necessary. Therefore, using brew switch is mostly useful when one wants to switch between two versions not too far apart.

2) Check, whether the version is available as a tap

Especially for larger software projects, it is very probably that there is a high enough demand for several (potentially API incompatible) major versions of a certain piece of software. As of March 2012, Homebrew 0.9 provides a mechanism for this: brew tap & the homebrew versions repository.

That versions repository may include backports of older versions for several formulae. (Mostly only the large and famous ones, but of course they’ll also have several formulae for postgresql.)

brew search postgresql will show you where to look:

$ brew search postgresql
postgresql
homebrew/versions/postgresql8    homebrew/versions/postgresql91
homebrew/versions/postgresql9    homebrew/versions/postgresql92

We can simply install it by typing

$ brew install homebrew/versions/postgresql8
Cloning into '/usr/local/Library/Taps/homebrew-versions'...
remote: Counting objects: 1563, done.
remote: Compressing objects: 100% (943/943), done.
remote: Total 1563 (delta 864), reused 1272 (delta 620)
Receiving objects: 100% (1563/1563), 422.83 KiB | 339.00 KiB/s, done.
Resolving deltas: 100% (864/864), done.
Checking connectivity... done.
Tapped 125 formula
==> Downloading http://ftp.postgresql.org/pub/source/v8.4.19/postgresql-8.4.19.tar.bz2
# …

Note that this has automatically tapped the homebrew/versions tap. (Check with brew tap, remove with brew untap homebrew/versions.) The following would have been equivalent:

$ brew tap homebrew/versions
$ brew install postgresql8

As long as the backported version formulae stay up-to-date, this approach is probably the best way to deal with older software.

3) Try some formula from the past

The following approaches are listed mostly for completeness. Both try to resurrect some undead formula from the brew repository. Due to changed dependencies, API changes in the formula spec or simply a change in the download URL, things may or may not work.

Since the whole formula directory is a git repository, one can install specific versions using plain git commands. However, we need to find a way to get to a commit where the old version was available.

a) historic times

Between August 2011 and October 2014, homebrew had a brew versions command, which spat out all available versions with their respective SHA hashes. As of October 2014, you have to do a brew tap homebrew/boneyard before you can use it. As the name of the tap suggests, you should probably only do this as a last resort.

E.g.

$ brew versions postgresql
Warning: brew-versions is unsupported and may be removed soon.
Please use the homebrew-versions tap instead:
  https://github.com/Homebrew/homebrew-versions
9.3.2    git checkout 3c86d2b Library/Formula/postgresql.rb
9.3.1    git checkout a267a3e Library/Formula/postgresql.rb
9.3.0    git checkout ae59e09 Library/Formula/postgresql.rb
9.2.4    git checkout e3ac215 Library/Formula/postgresql.rb
9.2.3    git checkout c80b37c Library/Formula/postgresql.rb
9.2.2    git checkout 9076baa Library/Formula/postgresql.rb
9.2.1    git checkout 5825f62 Library/Formula/postgresql.rb
9.2.0    git checkout 2f6cbc6 Library/Formula/postgresql.rb
9.1.5    git checkout 6b8d25f Library/Formula/postgresql.rb
9.1.4    git checkout c40c7bf Library/Formula/postgresql.rb
9.1.3    git checkout 05c7954 Library/Formula/postgresql.rb
9.1.2    git checkout dfcc838 Library/Formula/postgresql.rb
9.1.1    git checkout 4ef8fb0 Library/Formula/postgresql.rb
9.0.4    git checkout 2accac4 Library/Formula/postgresql.rb
9.0.3    git checkout b782d9d Library/Formula/postgresql.rb

As you can see, it advises against using it. Homebrew spits out all versions it can find with its internal heuristic and shows you a way to retrieve the old formulae. Let’s try it.

# First, go to the homebrew base directory
$ cd $( brew --prefix )
# Checkout some old formula
$ git checkout 6b8d25f Library/Formula/postgresql.rb
$ brew install postgresql
# … installing

Now that the older postgresql version is installed, we can re-install the latest formula in order to keep our repository clean:

$ git checkout -- Library/Formula/postgresql.rb

brew switch is your friend to change between the old and the new.

b) prehistoric times

For special needs, we may also try our own digging through the homebrew repo.

$ cd Library/Taps/homebrew/homebrew-core && git log -S'8.4.4' -- Formula/postgresql.rb

git log -S looks for all commits in which the string '8.4.4' was either added or removed in the file Library/Taps/homebrew/homebrew-core/Formula/postgresql.rb. We get two commits as a result.

commit 7dc7ccef9e1ab7d2fc351d7935c96a0e0b031552
Author: Aku Kotkavuo
Date:   Sun Sep 19 18:03:41 2010 +0300

    Update PostgreSQL to 9.0.0.

    Signed-off-by: Adam Vandenberg

commit fa992c6a82eebdc4cc36a0c0d2837f4c02f3f422
Author: David Höppner
Date:   Sun May 16 12:35:18 2010 +0200

    postgresql: update version to 8.4.4

Obviously, fa992c6a82eebdc4cc36a0c0d2837f4c02f3f422 is the commit we’re interested in. As this commit is pretty old, we’ll try to downgrade the complete homebrew installation (that way, the formula API is more or less guaranteed to be valid):

$ git checkout -b postgresql-8.4.4 fa992c6a82eebdc4cc36a0c0d2837f4c02f3f422
$ brew install postgresql
$ git checkout master
$ git branch -d postgresql-8.4.4

You may skip the last command to keep the reference in your git repository.

One note: When checking out the older commit, you temporarily downgrade your homebrew installation. So, you should be careful as some commands in homebrew might be different to the most recent version.

4) Manually write a formula

It’s not too hard and you may then upload it to your own repository. Used to be Homebrew-Versions, but that is now discontinued.

A.) Bonus: Pinning

If you want to keep a certain version of, say postgresql, around and stop it from being updated when you do the natural brew update; brew upgrade procedure, you can pin a formula:

$ brew pin postgresql

Pinned formulae are listed in /usr/local/Library/PinnedKegs/ and once you want to bring in the latest changes and updates, you can unpin it again:

$ brew unpin postgresql