OK, time for "Configure script debugging 101" :-).

>Config.log shows the following:
>
>configure:4003: checking for perl5
>configure:4003: checking for perl

The configure script is basically linear, i.e. each chunk of code
corresponds to a "checking for" section.  There may be loops (e.g. to
look for perl5 and perl), but basically you just read from top to bottom.

First, save your original ./configure script.  After you debug it you'll
want to put the original back in place.

Find the section of code that looks for Perl.  In the 2.4.2p2 version
it starts like this:

  for ac_prog in perl5 perl
  do

Add lines like this just before the "for" loop:

  echo "LOCSYSPATH is $LOCSYSPATH" >&5                  #JJ
  echo "LOCSYSPATH is $LOCSYSPATH" >&6                  #JJ

(I usually mark debugging changes with my initials so they are easy to
remove or find later.)

This outputs the LOCSYSPATH variable to your tty (file descriptor 5) and
config.log (file descriptor 6) so we can be certain it contains what you
think it does.  LOCSYSPATH is generated inside ./configure and should
be the Amanda libexec directory, your original $PATH, /usr/local/bin
and then a long list of "standard" locations:

  /bin:/usr/bin:/sbin:/usr/sbin:/usr/ucb:/usr/bsd:/etc:/usr/etc

A few lines later is the guts of the search:

  ac_dummy="$LOCSYSPATH"
  for ac_dir in $ac_dummy; do
    test -z "$ac_dir" && ac_dir=.
    if test -f $ac_dir/$ac_word; then
      ac_cv_path_PERL="$ac_dir/$ac_word"
      break
    fi
  done

Change it to look like this:

  ac_dummy="$LOCSYSPATH"
  for ac_dir in $ac_dummy; do
    test -z "$ac_dir" && ac_dir=.
    echo "Looking for \"$ac_word\" in \"$ac_dir\"" >&5  #JJ
    ls -lL "$ac_dir/$ac_word" 2>&1 | cat >&5            #JJ
    echo "Looking for \"$ac_word\" in \"$ac_dir\"" >&6  #JJ
    ls -lL "$ac_dir/$ac_word" 2>&1 | cat >&6            #JJ
    if test -f $ac_dir/$ac_word; then
      echo "Found \"$ac_dir/$ac_word\"" >&5             #JJ
      echo "Found \"$ac_dir/$ac_word\"" >&6             #JJ
      ac_cv_path_PERL="$ac_dir/$ac_word"
      break
    fi
  done

(There are, of course, an infinite number of ways to trace this process,
this is just the first one off the top of my head.  I'm known world wide
as a master of the "debug by print statement" school of thought :-)

At the end of this section is this:

  PERL="$ac_cv_path_PERL"
  if test -n "$PERL"; then
    echo "$ac_t""$PERL" 1>&6
  else
    echo "$ac_t""no" 1>&6
  fi

  test -n "$PERL" && break
  done

Right after the "done" put this:

  echo "PERL is \"$PERL\"" >&5                  #JJ
  echo "PERL is \"$PERL\"" >&6                  #JJ

If you're just going to concentrate on the perl code, add "exit 0"
as well.  That will stop the script at this point and speed up debugging.

Now, remove config.cache and rerun ./configure, then look at the log (or
what comes out on the terminal) and figure out what's going wrong:

  * Did LOCSYSPATH have everything you expected it to, in particular,
    /usr/bin?

  * Did the shell loop properly though all the PATH elements, again, in
    particular, /usr/bin?

  * Did the "ls -lL" show a match that should have happened?

  * Did the script say "Found" but yet it continued to loop?

Note that some vendors release truly amazingly broken versions
of sh.  It boggles the mind how they can do so, but it still happens.
It won't surprise me in the slightest to find out this is one of them.
For instance, it might not handle the long $LOCSYSPATH.  If that's the
case, you might shrink your PATH down to the bare minimum since what
you have probably duplicates a lot of what ./configure adds, e.g.:

  PATH=/bin:/usr/bin ... ./configure ...

If you have ksh (or even bash), you could also try running configure
with it:

  ... ksh -c "./configure ..."

(or change the #! line at the top of the script).

>configure:5736: checking for yywrap in -lfl
>configure:5755: gcc -o conftest  -I/usr/local/gnu/include -I/usr/local/gnu/inc
>lude/readline           conftest.c -lfl      1>&5
>/usr/bin/ld:
>Can't locate file for: -lfl

Note that you do not have any -L compiler options.  Where is libfl.a?
You may need to set the LDFLAGS environment variable, e.g.:

  LDFLAGS="-L/usr/local/lib ..." ... ./configure ...

>configure:6259: checking for readline.h
>configure:6269: gcc -E     conftest.c >/dev/null 2>conftest.out
>configure:6265:22: readline.h: No such file or directory
>...

The problem here is that there are no -I flags to the compiler.  Note
that on the -lfl test there are.

You have confused the use of CFLAGS and CPPFLAGS, which is understandable
-- they are often interchangeable, but not in this case.  CFLAGS should
only contain things for the compiler, such as optimization flags like
-g and -O.  It should *not* contain cpp options, such as -I and -D.
Those must go in CPPFLAGS.

So you should use:

  CPPFLAGS="-I/usr/local/gnu/include -I/usr/local/gnu/inc ..."

(along with LDFLAGS, etc).

>Is it possible that AMANDA's build programs may not be dealing well with the w
>ay
>the symlinks are resolved to their actual paths instead of the paths that are 
>set
>in the PATH variable...

That would be a sh problem, not an Amanda problem.  But I doubt that's
what's going on.

BTW, please keep some notes on all the fun you're having porting to a
new OS :-).  Amanda has a docs/SYSTEM.NOTES file that I'll be happy to
make you a prominent contributor to.

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

Reply via email to