Hi all,
I was trying to install git in a development and testing server we
have. The first problem was that AIX 'make' tool does NOT support
conditionals in makefiles, and display errors such...
[...]
"Makefile", line 1003: make: Dependency line needs colon or double
colon operator.
"Makefile", line 1007: make: Dependency line needs colon or double
colon operator.
"Makefile", line 1009: make: Dependency line needs colon or double
colon operator.
"Makefile", line 1011: make: Dependency line needs colon or double
colon operator.
[...]
... until I get stucked. Well, I solved this by just using GNU make,
then I compile:
$ /usr/linux/bin/make prefix=$HOME/apps/ NO_OPENSSL=1 NO_TCLTK=1
NO_EXPAT=1 PYTHON_PATH=/usr/local/bin/python
and it all works, with angels singing and everything... a testing repo
works fine for a test drive without installing, excepting 'git log'
that just don't display anything.
Now, when I feel good to install it...
$ /usr/linux/bin/make prefix=$HOME/apps/ NO_OPENSSL=1 NO_TCLTK=1
NO_EXPAT=1 PYTHON_PATH=/usr/local/bin/python install
[...]
install -d -m 755 '/myhomedir/apps/bin'
getopt: illegal option -- d
Usage: install [-c dira] [-f dirb] [-i] [-m] [-M mode] [-O owner]
[-G group] [-S] [-n dirc] [-o] [-s] file [dirx ...]
make: *** [install] Error 2
Now the installing process fails because of the AIX 'install' tool and
I wonder, can I patch/configure the installing process for AIX? May be
a set of utils for building in such systems would help some people.
PD: If you don't understand me please let me know it and I will try
again : ) My english could be horrible since I'm Argentinian.
PD2: I don't know if AIX python path is always /usr/local/bin/python,
but I've seen that git Makefiles set /usr/local/bin/python for FreeBSD
only:
git_remote_helpers/Makefile:
ifndef PYTHON_PATH
ifeq ($(uname_S),FreeBSD)
PYTHON_PATH = /usr/local/bin/python
else
PYTHON_PATH = /usr/bin/python
endif
endif
I think 'test' the file is a good way for auto-configuration.
Cheers,
Dario
On Thu, Jun 3, 2010 at 15:32, Dario Rodriguez [off-list ref] wrote:
and it all works, with angels singing and everything... a testing repo
works fine for a test drive without installing, excepting 'git log'
that just don't display anything.
How about PAGER=/bin/cat git log? If that works what's your pager, and
do other git commands that use the pager (like git show) work or fail?
$ /usr/linux/bin/make prefix=$HOME/apps/ NO_OPENSSL=1 NO_TCLTK=1
NO_EXPAT=1 PYTHON_PATH=/usr/local/bin/python install
[...]
install -d -m 755 '/myhomedir/apps/bin'
getopt: illegal option -- d
Usage: install [-c dira] [-f dirb] [-i] [-m] [-M mode] [-O owner]
[-G group] [-S] [-n dirc] [-o] [-s] file [dirx ...]
make: *** [install] Error 2
Now the installing process fails because of the AIX 'install' tool and
I wonder, can I patch/configure the installing process for AIX? May be
a set of utils for building in such systems would help some people.
Does AIX's install have something equivalent to GNU install's -d? The
-c and -f options look likely from that synopsis.
PD2: I don't know if AIX python path is always /usr/local/bin/python,
but I've seen that git Makefiles set /usr/local/bin/python for FreeBSD
only:
git_remote_helpers/Makefile:
ifndef PYTHON_PATH
ifeq ($(uname_S),FreeBSD)
PYTHON_PATH = /usr/local/bin/python
else
PYTHON_PATH = /usr/bin/python
endif
endif
That's presumably because Python is most likely installed via the
ports system on FreeBSD which drops it in /usr/local. How did you
install Python on AIX? Is it from some IBM package or another method
that's the most common & standard way to do it on AIX?.
If so the Makefile needs a test for AIX similar to the FreeBSD one.
From: Michael J Gruber <hidden> Date: 2016-06-15 22:48:54
Dario Rodriguez venit, vidit, dixit 03.06.2010 17:32:
Hi all,
I was trying to install git in a development and testing server we
have. The first problem was that AIX 'make' tool does NOT support
conditionals in makefiles, and display errors such...
[...]
"Makefile", line 1003: make: Dependency line needs colon or double
colon operator.
"Makefile", line 1007: make: Dependency line needs colon or double
colon operator.
"Makefile", line 1009: make: Dependency line needs colon or double
colon operator.
"Makefile", line 1011: make: Dependency line needs colon or double
colon operator.
[...]
... until I get stucked. Well, I solved this by just using GNU make,
then I compile:
$ /usr/linux/bin/make prefix=$HOME/apps/ NO_OPENSSL=1 NO_TCLTK=1
NO_EXPAT=1 PYTHON_PATH=/usr/local/bin/python
and it all works, with angels singing and everything... a testing repo
works fine for a test drive without installing, excepting 'git log'
that just don't display anything.
Now, when I feel good to install it...
$ /usr/linux/bin/make prefix=$HOME/apps/ NO_OPENSSL=1 NO_TCLTK=1
NO_EXPAT=1 PYTHON_PATH=/usr/local/bin/python install
[...]
install -d -m 755 '/myhomedir/apps/bin'
getopt: illegal option -- d
Usage: install [-c dira] [-f dirb] [-i] [-m] [-M mode] [-O owner]
[-G group] [-S] [-n dirc] [-o] [-s] file [dirx ...]
make: *** [install] Error 2
Now the installing process fails because of the AIX 'install' tool and
I wonder, can I patch/configure the installing process for AIX? May be
a set of utils for building in such systems would help some people.
AIX tools are a pain in the back end. If you want to compile & install
anything GNU there you need better tools. In case of install, there's
often something in /usr/ucb or /usr/ccs.
Are you using gcc or xlc btw?
PD: If you don't understand me please let me know it and I will try
again : ) My english could be horrible since I'm Argentinian.
It's certainly good enough!
PD2: I don't know if AIX python path is always /usr/local/bin/python,
but I've seen that git Makefiles set /usr/local/bin/python for FreeBSD
only:
git_remote_helpers/Makefile:
ifndef PYTHON_PATH
ifeq ($(uname_S),FreeBSD)
PYTHON_PATH = /usr/local/bin/python
else
PYTHON_PATH = /usr/bin/python
endif
endif
I think 'test' the file is a good way for auto-configuration.
You don't need to worry about python for git right now. It's set up for
a few things which are yet to come.
Cheers,
Michael
From: Tor Arntsen <hidden> Date: 2016-06-15 22:48:54
Re. building on AIX.
For AIX I've found that it's just better to always rely on the
freeware toolkit stuff, which comes on a separate toolkit CD and in
any case can be downloaded from
ftp://ftp.software.ibm.com:/aix/freeSoftware/aixtoolbox/RPMS/ppc
These are RPMs that you install via RPM which comes pre-installed on
AIX (or anyway is part of the standard AIX CDs).
On my own build the make, install, tar (gtar), grep, come from the
toolkit CD (the /usr/freeware/bin/ path). At least the first two seems
definitely mandatory.
Oh, and AIX /bin/sh is not particularly good - it's simpler to rely on
bash from the toolkit.
Depending on your AIX and compiler versions you may need some
additional changes. Gary Vaughan have posted patches which include
updates that will improve the AIX experience. In addition to that, if
you have the old XlC 5.0 compiler you will probably be better off at
this point to use gcc from the toolkit. Otherwise you'll need those
patches, and also one I posted which removes some C++ comments (I
should probably re-post that one because it's not against the latest
git repo version anymore).
All that been said, I build on AIX as follows, using configure (which
takes care of some other issues at the moment).
SHELL_PATH=/opt/freeware/bin/bash
PERL_PATH=/usr/local/special/bin/perl ./configure CC=cc
CFLAGS=-Dinline=""
and
make SHELL_PATH=/opt/freeware/bin/bash PERL_PATH=/usr/local/special/bin/perl
followed by the same, with 'install'
That's with the old compiler and patches applied. Without patches
you'll either have to rely on GCC (and remove those CC and CFLAGS
lines, or change CC to gcc), or, with a newer (say, v10) IBM
compiler), the -Dinline="" may not be needed.
The only problem now is that some stuff (git rebase --interactive
IIRC) will still not work, if you're on an AIX version with Perl 5.6
(some things in git needs 5.8). AIX 6.1 has Perl 5.8, but some
customers will downgrade to 5.6 because of bad performance problems
with 5.8 on AIX.
-Tor
From: Tor Arntsen <hidden> Date: 2016-06-15 22:48:54
On Fri, Jun 4, 2010 at 11:13, Tor Arntsen [off-list ref] wrote:
The only problem now is that some stuff (git rebase --interactive
IIRC) will still not work, if you're on an AIX version with Perl 5.6
(some things in git needs 5.8).
Thinking harder I now believe it was 'git add --patch' which needs Perl >= 5.8.
-Tor
On Fri, Jun 4, 2010 at 6:13 AM, Tor Arntsen [off-list ref] wrote:
Re. building on AIX.
For AIX I've found that it's just better to always rely on the
freeware toolkit stuff, which comes on a separate toolkit CD and in
any case can be downloaded from
ftp://ftp.software.ibm.com:/aix/freeSoftware/aixtoolbox/RPMS/ppc
These are RPMs that you install via RPM which comes pre-installed on
AIX (or anyway is part of the standard AIX CDs).
On my own build the make, install, tar (gtar), grep, come from the
toolkit CD (the /usr/freeware/bin/ path). At least the first two seems
definitely mandatory.
Oh, and AIX /bin/sh is not particularly good - it's simpler to rely on
bash from the toolkit.
As I'm not the sysadmin, and git is not the project's tool, and the
server is in other city... I cannot install things from the CD :(
Another thing is that RPM utility is there... but I think I will not
have enough permissions to install software in such way. Development
teams compile utilities when needed (or not) and install in $HOME/bin.
I will need 'install's sources or an alternate way to install GIT...
Anyway, the 'make test' begun yesterday with a lot of failures... so,
I don't know if I'ill be able to use GIT on AIX soon, but may be I can
help to make it work.
Depending on your AIX and compiler versions you may need some additional changes.
AIX is 5.2(.0.0), PERL is 5.8.0, IBM(R) XL C/C++ Enterprise Edition V7.0
Gary Vaughan have posted patches which include
updates that will improve the AIX experience. In addition to that, if
you have the old XlC 5.0 compiler you will probably be better off at
this point to use gcc from the toolkit. Otherwise you'll need those
patches, and also one I posted which removes some C++ comments (I
should probably re-post that one because it's not against the latest
git repo version anymore).
All that been said, I build on AIX as follows, using configure (which
takes care of some other issues at the moment).
SHELL_PATH=/opt/freeware/bin/bash
PERL_PATH=/usr/local/special/bin/perl ./configure CC=cc
CFLAGS=-Dinline=""
and
make SHELL_PATH=/opt/freeware/bin/bash PERL_PATH=/usr/local/special/bin/perl
followed by the same, with 'install'
That's with the old compiler and patches applied. Without patches
you'll either have to rely on GCC (and remove those CC and CFLAGS
lines, or change CC to gcc), or, with a newer (say, v10) IBM
compiler), the -Dinline="" may not be needed.
The only problem now is that some stuff (git rebase --interactive
IIRC) will still not work, if you're on an AIX version with Perl 5.6
(some things in git needs 5.8). AIX 6.1 has Perl 5.8, but some
customers will downgrade to 5.6 because of bad performance problems
with 5.8 on AIX.
-Tor
I'ill try compiling 'install' (i don't know where the sources are)
Thank'u man,
Dario
From: Tor Arntsen <hidden> Date: 2016-06-15 22:48:54
On Fri, Jun 4, 2010 at 16:22, Dario Rodriguez [off-list ref] wrote:
AIX is 5.2(.0.0), PERL is 5.8.0, IBM(R) XL C/C++ Enterprise Edition V7.0
I think that compiler is reasonably OK to use, it'll probably not
choke on anything in particular. Perl OK too.
I'ill try compiling 'install' (i don't know where the sources are)
It's in 'coreutils' these days, but that package includes a lot of stuff.
Maybe you could get away with just using the script-version of install
which comes with coreutils itself (because it'll need an install tool
to use before 'install' itself is installed..).
I'm attaching a copy. To use it it should be sufficient to use
INSTALL=path-to/install-sh make install
or something like that.
-Tor
On Fri, Jun 4, 2010 at 11:38 AM, Tor Arntsen [off-list ref] wrote:
On Fri, Jun 4, 2010 at 16:22, Dario Rodriguez [off-list ref] wrote:
quoted
AIX is 5.2(.0.0), PERL is 5.8.0, IBM(R) XL C/C++ Enterprise Edition V7.0
I think that compiler is reasonably OK to use, it'll probably not
choke on anything in particular. Perl OK too.
quoted
I'ill try compiling 'install' (i don't know where the sources are)
It's in 'coreutils' these days, but that package includes a lot of stuff.
Maybe you could get away with just using the script-version of install
which comes with coreutils itself (because it'll need an install tool
to use before 'install' itself is installed..).
I'm attaching a copy. To use it it should be sufficient to use
INSTALL=path-to/install-sh make install
or something like that.
-Tor
Hmm... I will check makefiles today, but there is something wrong
here, take a look:
$ INSTALL=$HOME/bin/install-sh /usr/linux/bin/make
prefix=$HOME/.gitbin NO_OPENSSL=1 NO_TCLTK=1 NO_EXPAT=1
PYTHON_PATH=/usr/local/bin/python install
SUBDIR perl
SUBDIR git_remote_helpers
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
SUBDIR templates
install -d -m 755 '/aplicaciones/D0/imei/usuarios/tximeid0/.gitbin/bin'
getopt: illegal option -- d
Usage: install [-c dira] [-f dirb] [-i] [-m] [-M mode] [-O owner]
[-G group] [-S] [-n dirc] [-o] [-s] file [dirx ...]
make: *** [install] Error 2
It's not using install-sh since it supports -d ... and lets take a
quick look at Makefiles:
$ find . -name Makefile -exec grep install {} \; | grep -v "^#" | grep INSTALL
INSTALL?=install
INSTALL_INFO=install-info
INSTALL = install
INSTALL = ginstall
INSTALL = ginstall
INSTALL = /usr/ucb/install
INSTALL = /bin/install
$(INSTALL) $(install_bindir_programs) '$(DESTDIR_SQ)$(bindir_SQ)'
INSTALL ?= install
INSTALL = install
INSTALL ?= install
INSTALL ?= install
It seems as if it's looking for /bin/install ... even when I wrote
'INSTALL=$HOME/bin/install-sh'
I have no more time, and will access the server next monday... but I'm
going home and may be i'ill take a look at this to know how to do it,
thanks 4 the script ; )
Cheers,
Dario
From: Jakub Narebski <hidden> Date: 2016-06-15 22:48:55
Tor Arntsen [off-list ref] writes:
On Fri, Jun 4, 2010 at 16:22, Dario Rodriguez [off-list ref] wrote:
quoted
I'ill try compiling 'install' (i don't know where the sources are)
It's in 'coreutils' these days, but that package includes a lot of stuff.
Maybe you could get away with just using the script-version of install
which comes with coreutils itself (because it'll need an install tool
to use before 'install' itself is installed..).
I'm attaching a copy. To use it it should be sufficient to use
INSTALL=path-to/install-sh make install
or something like that.
I wonder if it would be better to simply include fallback portable
install-sh in git sources.
BTW. shouldn't we define and use INSTALL_D in Makefile?
--
Jakub Narebski
Poland
ShadeHawk on #git
On Sat, Jun 5, 2010 at 8:44 AM, Jakub Narebski [off-list ref] wrote:
Tor Arntsen [off-list ref] writes:
quoted
On Fri, Jun 4, 2010 at 16:22, Dario Rodriguez [off-list ref] wrote:
quoted
quoted
I'ill try compiling 'install' (i don't know where the sources are)
It's in 'coreutils' these days, but that package includes a lot of stuff.
Maybe you could get away with just using the script-version of install
which comes with coreutils itself (because it'll need an install tool
to use before 'install' itself is installed..).
I'm attaching a copy. To use it it should be sufficient to use
INSTALL=path-to/install-sh make install
or something like that.
I wonder if it would be better to simply include fallback portable
install-sh in git sources.
BTW. shouldn't we define and use INSTALL_D in Makefile?
--
Jakub Narebski
Poland
ShadeHawk on #git
I think so about the install-sh, but about the Makefiles I wonder if
it's not better to reuse current INSTALL, maybe if install-sh is used,
then there is no need for using other 'install' program, excepting the
case in wich the user sets INSTALL commandline.
Blessing,
Dario
From: Jakub Narebski <hidden> Date: 2016-06-15 22:48:55
On Sat, 5 Jun 2010, Dario Rodriguez wrote:
On Sat, Jun 5, 2010 at 8:44 AM, Jakub Narebski [off-list ref] wrote:
quoted
Tor Arntsen [off-list ref] writes:
quoted
Maybe you could get away with just using the script-version of install
which comes with coreutils itself (because it'll need an install tool
to use before 'install' itself is installed..).
I'm attaching a copy. To use it it should be sufficient to use
INSTALL=path-to/install-sh make install
or something like that.
I wonder if it would be better to simply include fallback portable
install-sh in git sources.
BTW. shouldn't we define and use INSTALL_D in Makefile?
I think so about the install-sh, but about the Makefiles I wonder if
it's not better to reuse current INSTALL, maybe if install-sh is used,
then there is no need for using other 'install' program, excepting the
case in wich the user sets INSTALL commandline.
Well, if there were install-sh script in git sources, we could uncomment
#AC_PROG_INSTALL # needs install-sh or install.sh in sources
line in configure.ac, then ./configure would automatically detect and
select 'install' program or script to use. The autoconf documentation
(autoconf.info) says:
This macro screens out various instances of `install' known not to
work. It prefers to find a C program rather than a shell script,
for speed. [...]
Autoconf comes with a copy of `install-sh' that you can use. If
you use `AC_PROG_INSTALL', you must include either `install-sh' or
`install.sh' in your distribution, or `configure' will produce an
error message saying it can't find them--even if the system you're
on has a good `install' program. This check is a safety measure
to prevent you from accidentally leaving that file out, which
would prevent your package from installing on systems that don't
have a BSD-compatible `install' program.
So I guess we should also prefer install program for speed, even if we
do not use ./configure script.
--
Jakub Narębski
Poland