{"thread":{"id":"39049","subject":"Installing git binaries on a non-default directory (Ubuntu)","startedAt":"2015-04-10T16:34:26Z","lastAt":"2015-04-23T20:17:18Z","messageCount":4,"participants":["Gianpaolo Macario","Junio C Hamano","Macario, Gianpaolo","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"259229","messageId":"loom.20150410T183218-536@post.gmane.org","threadId":"39049","inReplyTo":null,"subject":"Installing git binaries on a non-default directory (Ubuntu)","fromName":"Gianpaolo Macario","fromEmail":"gianpaolo_macario@mentor.com","sentAt":"2015-04-10T16:34:26Z","receivedAt":"2015-04-10T16:34:26Z","isPatch":false,"sender":{"key":"gianpaolo_macario@mentor.com","avatar":null},"body":"Hello,\n\nI need to distribute a set of programs - including a recent version of git - \nto a large set of users.\n\nThe users are running different versions of Linux (Ubuntu from 10.04 \nonwards) and are not supposed to know how to build the programs from \nsources.\nAlso they should be able to choose where to install the binaries.\n\nMy idea was to build git on the oldest supported machine (Ubuntu 10.04.4 32-\nbit), then create a tarball incluing the installation directory which was \ncreated by git \"make install\":\n\nBy some googling and after reading the git sources and the commit logs I \nassumed that the `RUNTIME_PREFIX` option\n(see <https://github.com/git/git/blob/master/exec_cmd.c>) was designed for \nthat purpose, so I did the following:\n\n    $ mkdir -p ~/tmp\n    $ cd ~/tmp\n    $ wget http://kernel.org/pub/software/scm/git/git-2.3.5.tar.gz\n    $ tar -xvzf git-2.3.5.tar.gz\n    $ cd git-2.3.5\n    $ ./configure --prefix=$HOME/git-install \\\n    --with-curl --with-openssl --without-tcltk \\\n    CFLAGS=\"${CFLAGS} -DRUNTIME_PREFIX=1 `pkg-config --static --libs \nlibcurl`\"\n    $ make\n    $ make install\n    $ cd $HOME/git-install\n    $ tar -cvzf ~/git-install-2.3.5.tar.gz .\n    $ cd\n    $ rm -rf ~/tmp/git-2.3.5\n    $ rm -rf $HOME/git-install\n\nEverything seems OK as long as the tarball is extracted under the same\ndirectory where the binaries where installed by `make install`\n(in my case, `/home/gmacario/git-install`):\n\n    gmacario@alm-gm-oipbuild05:~$ ~/git-install/bin/git --version\n    git version 2.3.5\n    gmacario@alm-gm-oipbuild05:~$ ~/git-install/bin/git --exec-path\n    /home/gmacario/git-install/libexec/git-core\n    gmacario@alm-gm-oipbuild05:~$\n\nHowever if the user chooses to install it somewhere else - for instance\n\n    $ sudo mkdir -p /opt/tools\n    $ sudo chown $USER /opt/tools\n    $ cd /opt/tools\n    $ tar -xvzf ~/git-install-2.3.5.tar.gz\n\ncommand `git --exec-path` still returns the directory where\nthe binaries were installed by `make install`:\n\n    gmacario@alm-gm-oipbuild05:~$ /opt/tools/bin/git --exec-path\n    /home/gmacario/git-install/libexec/git-core\n    gmacario@alm-gm-oipbuild05:~$\n\nAs a result non-builtin commands such as \"git clone https://xxx\" will not \nwork.\nAlso the templates cannot be found as shown below:\n\n    gmacario@alm-gm-oipbuild05:~$ /opt/tools/bin/git clone \nhttps://github.com/gmacario/hello.git\n    Cloning into 'hello'...\n    warning: templates not found /home/gmacario/git-install/share/git-\ncore/templates\n    fatal: Unable to find remote helper for 'https'\n    gmacario@alm-gm-oipbuild05:~$\n\nEven though it is a nuisance I was able to work around the wrong \"--exec-\npath\"\nby setting the \"GIT_EXEC_PATH\" environment variable, but I still cannot\nunderstand how to have the templates found in the proper directory.\n\nAccording to \n<https://github.com/git/git/commit/35fb0e8633217f602360a9987af51c4b960e7850>\nI am afraid that relocatable binaries is only half-baked in Unix:\n\n  Note that RUNTIME_PREFIX only works on Windows, though adding\n  support on Unix should not be too hard.  The implementation\n  requires argv0_path to be set to an absolute path.  argv0_path must\n  point to the directory of the executable.  We use assert() to\n  verify this in debug builds.  On Windows, the wrapper for main()\n  (see compat/mingw.h) guarantees that argv0_path is correctly\n  initialized.  On Unix, further work is required before\n  RUNTIME_PREFIX can be enabled.\n\nHas anybody tried to do the same? Do you have any advices to give me?\n\nThanks,\n\nGianpaolo Macario\n"},{"id":"259278","messageId":"xmqq7ftg4l73.fsf@gitster.dls.corp.google.com","threadId":"39049","inReplyTo":"loom.20150410T183218-536@post.gmane.org","subject":"Re: Installing git binaries on a non-default directory (Ubuntu)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-13T06:05:36Z","receivedAt":"2015-04-13T06:05:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gianpaolo Macario <gianpaolo_macario@mentor.com> writes:\n\n> By some googling and after reading the git sources and the commit logs I \n> assumed that the `RUNTIME_PREFIX` option\n> (see <https://github.com/git/git/blob/master/exec_cmd.c>) was designed for \n> that purpose,\n\nI do not think so.\n\nThe standard procedure to stage into a temporary with \"make install\"\nand then make a tarball is done by using DESTDIR, e.g. something\nlike\n\n  $ make DESTDIR=/var/tmp/gittt ...other args... install\n  $ tar zCf /var/tmp/gittt git-version.tar.gz\n"},{"id":"259286","messageId":"0CCD6BBA210ECA418BCD82271FCFD94C556A3CEA@EU-MBX-03.mgc.mentorg.com","threadId":"39049","inReplyTo":"xmqq7ftg4l73.fsf@gitster.dls.corp.google.com","subject":"RE: Installing git binaries on a non-default directory (Ubuntu)","fromName":"Macario, Gianpaolo","fromEmail":"gianpaolo_macario@mentor.com","sentAt":"2015-04-13T11:10:51Z","receivedAt":"2015-04-13T11:10:51Z","isPatch":false,"sender":{"key":"gianpaolo_macario@mentor.com","avatar":null},"body":"Hello Juno,\n\n> Gianpaolo Macario <gianpaolo_macario@mentor.com> writes:\n> \n> > By some googling and after reading the git sources and the commit logs\n> > I assumed that the `RUNTIME_PREFIX` option (see\n> > <https://github.com/git/git/blob/master/exec_cmd.c>) was designed for\n> > that purpose,\n> \n> I do not think so.\n> \n> The standard procedure to stage into a temporary with \"make install\"\n> and then make a tarball is done by using DESTDIR, e.g. something like\n> \n>   $ make DESTDIR=/var/tmp/gittt ...other args... install\n>   $ tar zCf /var/tmp/gittt git-version.tar.gz\n\n[Macario, Gianpaolo] Thanks for your reply.\n\nUnfortunately 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.\n\nHow 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` ?\n\nI tried the following\n\n    $ mkdir -p ~/tmp\n    $ cd ~/tmp\n    $ wget http://kernel.org/pub/software/scm/git/git-2.3.5.tar.gz\n    $ tar -xvzf git-2.3.5.tar.gz\n    $ cd git-2.3.5\n    $ ./configure --prefix= \\\n    --with-curl --with-openssl --without-tcltk \\\n    CFLAGS=\"${CFLAGS} `pkg-config --static --libs libcurl`\"\n    $ make\n    $ make DESTDIR=/var/tmp/gittt install\n    $ cd /var/tmp/gittt\n    $ tar -cvzf ~/git-install-2.3.5.tar.gz .\n    $ cd\n    $ rm -rf ~/tmp/git-2.3.5\n    $ rm -rf /var/tmp/gittt\n\nthen extracted the tarball\n\n    $ sudo mkdir -p /opt/tools\n    $ sudo chown $USER /opt/tools\n    $ cd /opt/tools\n    $ tar -xvzf ~/git-install-2.3.5.tar.gz\n\nThis is the result when executing\n\n    $ /opt/tools/bin/git --exec-path\n    /libexec/git-core\n\nI wanted to have it return `/opt/tools/libexec/git-core` instead.\n\nIf I do not specify any `--prefix=xxx` when running `./configure`, this defaults to `/usr/local` which is not good either.\n\nThanks in advance, and apologies if I am doing something stupid...\n\nGianpaolo\n"},{"id":"259915","messageId":"20150423201718.GB28338@peff.net","threadId":"39049","inReplyTo":"0CCD6BBA210ECA418BCD82271FCFD94C556A3CEA@EU-MBX-03.mgc.mentorg.com","subject":"Re: Installing git binaries on a non-default directory (Ubuntu)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-23T20:17:18Z","receivedAt":"2015-04-23T20:17:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 13, 2015 at 11:10:51AM +0000, Macario, Gianpaolo wrote:\n\n> Unfortunately it looks to me that the `--prefix=xxx` option provided\n> to configure will be hardcoded to the path returned by 'git\n> --exec-path', and I do not see how this may actually be made dependent\n> on the directory where the binary tarball will be extracted.\n\nSorry for the late reply, but I just noticed this and happened to be\nlooking at RUNTIME_PREFIX issues recently.\n\nYou're right that no amount of --prefix or other settings can help you\nwith making binaries that are relocatable after the fact. You do need\nsomething like RUNTIME_PREFIX, but as you found, it does not work very\nwell on Unix systems.\n\nI do not know if there are other issues, but at least the _first_ issue\nthat must be dealt with is that git_extract_argv0_path may get a bare\nname like \"git\", without its PATH. So you will have to compute the full\npath to the binary in order to find the rest of the files.\n\nThere was some minor discussion here:\n\n  http://thread.gmane.org/gmane.comp.version-control.git/267143/focus=267606\n\n(see the notes after the commit message, and the response from\nJonathan).\n\nI hope that helps.\n\n-Peff\n"}]}