Installing git binaries on a non-default directory (Ubuntu)

Hello,

I need to distribute a set of programs - including a recent version of git - to a large set of users.

The users are running different versions of Linux (Ubuntu from 10.04 onwards) and are not supposed to know how to build the programs from sources. Also they should be able to choose where to install the binaries.

My idea was to build git on the oldest supported machine (Ubuntu 10.04.4 32- bit), then create a tarball incluing the installation directory which was created by git "make install":

By some googling and after reading the git sources and the commit logs I assumed that the `RUNTIME_PREFIX` option (see <https://github.com/git/git/blob/master/exec_cmd.c>) was designed for that purpose, so I did the following:

    $ mkdir -p ~/tmp
    $ cd ~/tmp
    $ wget http://kernel.org/pub/software/scm/git/git-2.3.5.tar.gz
    $ tar -xvzf git-2.3.5.tar.gz
    $ cd git-2.3.5
    $ ./configure --prefix=$HOME/git-install \
    --with-curl --with-openssl --without-tcltk \
    CFLAGS="${CFLAGS} -DRUNTIME_PREFIX=1 `pkg-config --static --libs 
libcurl`"
    $ make
    $ make install
    $ cd $HOME/git-install
    $ tar -cvzf ~/git-install-2.3.5.tar.gz .
    $ cd
    $ rm -rf ~/tmp/git-2.3.5
    $ rm -rf $HOME/git-install

Everything seems OK as long as the tarball is extracted under the same directory where the binaries where installed by `make install` (in my case, `/home/gmacario/git-install`):

    gmacario@alm-gm-oipbuild05:~$ ~/git-install/bin/git --version
    git version 2.3.5
    gmacario@alm-gm-oipbuild05:~$ ~/git-install/bin/git --exec-path
    /home/gmacario/git-install/libexec/git-core
    gmacario@alm-gm-oipbuild05:~$

However if the user chooses to install it somewhere else - for instance

    $ sudo mkdir -p /opt/tools
    $ sudo chown $USER /opt/tools
    $ cd /opt/tools
    $ tar -xvzf ~/git-install-2.3.5.tar.gz

command `git --exec-path` still returns the directory where the binaries were installed by `make install`:

    gmacario@alm-gm-oipbuild05:~$ /opt/tools/bin/git --exec-path
    /home/gmacario/git-install/libexec/git-core
    gmacario@alm-gm-oipbuild05:~$

As a result non-builtin commands such as "git clone https://xxx" will not work. Also the templates cannot be found as shown below:

    gmacario@alm-gm-oipbuild05:~$ /opt/tools/bin/git clone 
https://github.com/gmacario/hello.git
    Cloning into 'hello'...
    warning: templates not found /home/gmacario/git-install/share/git-
core/templates
    fatal: Unable to find remote helper for 'https'
    gmacario@alm-gm-oipbuild05:~$

Even though it is a nuisance I was able to work around the wrong "--exec- path" by setting the "GIT_EXEC_PATH" environment variable, but I still cannot understand how to have the templates found in the proper directory.

According to <https://github.com/git/git/commit/35fb0e8633217f602360a9987af51c4b960e7850> I am afraid that relocatable binaries is only half-baked in Unix:

  Note that RUNTIME_PREFIX only works on Windows, though adding
  support on Unix should not be too hard.  The implementation
  requires argv0_path to be set to an absolute path.  argv0_path must
  point to the directory of the executable.  We use assert() to
  verify this in debug builds.  On Windows, the wrapper for main()
  (see compat/mingw.h) guarantees that argv0_path is correctly
  initialized.  On Unix, further work is required before
  RUNTIME_PREFIX can be enabled.

Has anybody tried to do the same? Do you have any advices to give me?

Thanks,

Gianpaolo Macario

Gianpaolo Macario <gianpaolo_macario@mentor.com> writes:

I do not think so.

The standard procedure to stage into a temporary with "make install" and then make a tarball is done by using DESTDIR, e.g. something like

  $ make DESTDIR=/var/tmp/gittt ...other args... install
  $ tar zCf /var/tmp/gittt git-version.tar.gz

Hello Juno,

[Macario, Gianpaolo] Thanks for your reply.

Unfortunately it looks to me that the `--prefix=xxx` option provided to configure will be hardcoded to the path returned by 'git --exec-path', and I do not see how this may actually be made dependent on the directory where the binary tarball will be extracted.

How should I configure/make git to have `<install_path>/bin/git --exec-path` return a path which depends on `<install_path>` rather than what provided to `./configure` ?

I tried the following

    $ mkdir -p ~/tmp
    $ cd ~/tmp
    $ wget http://kernel.org/pub/software/scm/git/git-2.3.5.tar.gz
    $ tar -xvzf git-2.3.5.tar.gz
    $ cd git-2.3.5
    $ ./configure --prefix= \
    --with-curl --with-openssl --without-tcltk \
    CFLAGS="${CFLAGS} `pkg-config --static --libs libcurl`"
    $ make
    $ make DESTDIR=/var/tmp/gittt install
    $ cd /var/tmp/gittt
    $ tar -cvzf ~/git-install-2.3.5.tar.gz .
    $ cd
    $ rm -rf ~/tmp/git-2.3.5
    $ rm -rf /var/tmp/gittt

then extracted the tarball

    $ sudo mkdir -p /opt/tools
    $ sudo chown $USER /opt/tools
    $ cd /opt/tools
    $ tar -xvzf ~/git-install-2.3.5.tar.gz

This is the result when executing

    $ /opt/tools/bin/git --exec-path
    /libexec/git-core

I wanted to have it return `/opt/tools/libexec/git-core` instead.

If I do not specify any `--prefix=xxx` when running `./configure`, this defaults to `/usr/local` which is not good either.

Thanks in advance, and apologies if I am doing something stupid...

Gianpaolo

On Mon, Apr 13, 2015 at 11:10:51AM +0000, Macario, Gianpaolo wrote:

Sorry for the late reply, but I just noticed this and happened to be looking at RUNTIME_PREFIX issues recently.

You're right that no amount of --prefix or other settings can help you with making binaries that are relocatable after the fact. You do need something like RUNTIME_PREFIX, but as you found, it does not work very well on Unix systems.

I do not know if there are other issues, but at least the _first_ issue that must be dealt with is that git_extract_argv0_path may get a bare name like "git", without its PATH. So you will have to compute the full path to the binary in order to find the rest of the files.

There was some minor discussion here:

  http://thread.gmane.org/gmane.comp.version-control.git/267143/focus=267606

(see the notes after the commit message, and the response from Jonathan).

I hope that helps.

-Peff