All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Schumacher <schumact@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: Building GIT on older systems.
Date: Wed, 29 Feb 2012 15:17:24 -0700	[thread overview]
Message-ID: <4F4EA3F4.7040501@gmail.com> (raw)
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:
> 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.
>
>> 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


> 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.

  reply	other threads:[~2012-02-29 22:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAFqtsHfrk89qHexg8VwMZnKwgWDqbseJNNKFSUkwDtVKX_t=5g@mail.gmail.com>
2012-02-29 20:22 ` Building GIT on older systems Tim Schumacher
2012-02-29 20:35   ` Dan Johnson
2012-02-29 20:55   ` Jeff King
2012-02-29 22:17     ` Tim Schumacher [this message]
2012-02-29 21:00   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F4EA3F4.7040501@gmail.com \
    --to=schumact@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.