Re: Building GIT on older systems.

From: Tim Schumacher <schumact@gmail.com>
Date: Feb 29, 2012, 22:17 UTC
Message-ID: <4F4EA3F4.7040501@gmail.com>
In-Reply-To: <20120229205510.GA628@sigill.intra.peff.net>

Hi Peff, thanks!

Comments in-line below.

-Tim

On 2/29/2012 1:55 PM, Jeff King wrote:

Show 28 quoted lines

> On Wed, Feb 29, 2012 at 01:22:21PM -0700, Tim Schumacher wrote:
>
>> After a long battle trying to get git to compile on my dev boxes I am
>> seeking help from the gurus...  I have an old system, redhat linux
>> 7.3, with a 2.4.18 kernel with gcc 2.96 toolchain.  Unfortuneatly,
>> upgrading is not currently an option.
> That's pretty old, but I would think git should be build-able on it with
> the right Makefile flags set. We build on even older versions of
> Solaris.
>
>> I have figured out so far that I can run the command
>>
>> make NO_NSEC=true
>>
>> to get past the time struct compile error.
> As an aside, you can put definitions like this into config.mak, which is
> read automatically by the Makefile. Then you don't have to specify them
> on the command line for each 'make' invocation.
>
>> After that, I was able to hand edit the Makefile to set
>>
>> BASIC_LDFLAGS = -ldl
>>
>> so linking the git-imap-send program succeeds (was failing to link
>> against this library for some reason...).
> What was the link error? I don't know why imap-send would need to link
> against -ldl. However, you should be able to just put -ldl into the
> LDFLAGS on the command-line or in config.mak.

The actual link errors were unresolved references to the dl* family of functions: dlopen, dlsym, etc.

>> I tried to run configure with these options, but it did not seem to
>> take, only setting NO_NSEC=true to the make command line seems to
>> work.
> Was NO_NSEC set in the resulting config.mak.autogen?

Not sure.  I set up the config.mak though so it is sticking with that.

Show 19 quoted lines

>
>> Anyway, now I get to the point in the build where it goes into the
>> perl subdir and fails with:
>>
>>     SUBDIR perl
>> /bin/sh: -c: line 3: syntax error near unexpected token
>> `"s<\Q++LOCALEDIR++\E></'
>> /bin/sh: -c: line 3: `        -e "pm_to_blib({qw{Git/I18N.pm
>> blib/lib/Git/I18N.pm private-Error.pm blib/lib/Error.pm Git.pm
>> blib/lib/Git.pm}},'blib/lib/auto','/usr/bin/perl -pe
>> "s<\Q++LOCALEDIR++\E></usr/local/git-1.7.9.2/share/locale>"')"'
>> make[2]: *** [pm_to_blib] Error 2
>> make[1]: *** [all] Error 2
>> make: *** [all] Error 2
> I haven't seen that before. The snippet mentioned in the error message
> is actually written to the Makefile by Makefile.PL. Can you show us the
> relevant part of the Makefile (i.e., the command that contains
> "++LOCALEDIR++") so we can see if it's broken? My suspicion is that
> there is an error in the generation of the Makefile by Makefile.PL.

Around line 108 in my GIT_HOME/perl/perl.mak I have this: (line numbers are from VI)

     108 PM_FILTER = $(PERL) -pe 
"s<\Q++LOCALEDIR++\E></home/tschumacher/share/locale>"

and later PM_FILTER is used as:

     713
     714 # --- MakeMaker pm_to_blib section:
     715
     716 pm_to_blib: $(TO_INST_PM)
     717     @$(PERL) "-I$(INST_ARCHLIB)" "-I$(INST_LIB)" \
     718     "-I$(PERL_ARCHLIB)" "-I$(PERL_LIB)" -MExtUtils::Install \
     719         -e 
"pm_to_blib({qw{$(PM_TO_BLIB)}},'$(INST_LIB)/auto','$(PM_FILTER)')"
     720     @$(TOUCH) $@
     721

Show 23 quoted lines

> Although your perl is so old the first step may be either to turn off
> perl or upgrade to a newer version (see below).
>
>> A couple questions I have so far:
>> (1)  how can I make make output the actual command it is executing so
>> I can try to debug things more quickly?
> Doing "make V=1" will be more verbose. You can also use "make -d" to get
> more output about which rules and commands are being followed, but its
> output can be a bit overwhelming (and I don't think you have a make
> problem, exactly).
>
>> (2)  how can I configure the Makefile to automatically set -ldl as
>> well as the NO_NSEC flag?
> Put it in LDFLAGS.
>
>> (3)  My perl -v output: This is perl, v5.6.1 built for i386-linux.  Is
>> this sufficient?
> These days we require at least 5.8, mostly because no developers are using 5.6
> and support for it is bit-rotting. If your perl is that old, probably
> setting NO_PERL is the best option. You will lose a few perl features
> like interactive patch selection ("git add -p") and git-svn.
>
> -Peff

I am trying to install a newer version of perl on this box and will retry the configure adding --with-perl option and see how it goes.