[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: autoreconf warning message: autom4te: cannotlockautom4te.cache/reque
Re: autoreconf warning message: autom4te: cannotlockautom4te.cache/requests with mode 2: Invalid argument
Wed, 14 Mar 2007 22:47:01 -0600
David Byron wrote:
> <1:257> % /opt/perl/bin/perl -v
> -bash: /opt/perl/bin/perl: No such file or directory
> Here's some info from config.log:
> uname -m = 9000/782
> uname -r = B.11.00
> uname -s = HP-UX
> uname -v = A
HP-UX did not start shipping /opt/perl/bin/perl until HP-UX 11.11. So
your system is just a little too old. On 11.11 that would be v5.6.1
and on 11.23 that would be v5.8.0.
> > I believe it is quite likely that you will not need to
> > build perl yourself at all.
> I'm building perl from source because autoconf says it wants perl 5.00503
> and I've got 5.00502.
I have successfully used 5.00502 for a long time. I was in the same
position of only having 5.00502 available for various reasons and ran
into the same problem.
Try this scriptly patch. This is from an rpm spec file %prep build
section for an HP-UX build of autoconf. I don't know how much of this
still applies. This was for the 2.59 version now quite dated.
# We only have perl 5.005_02 available at the moment. And that is
# good enough so override this check. Do it here instead of as a patch
# so we can preserve timestamps because otherwise we need to bootstrap
# the tools.
for f in $(find . -type f -print0 \
| xargs -r0 grep -l 5.005_03); do
sed 's/5.005_03/5.005_02/' $f > $f.new
chmod --reference $f $f.new
touch --reference $f $f.new
mv -f $f.new $f
# autoconf inadvertantly created a requirement on perl-5.5 by using
# the single argument version of mkdir without a mode. Add the mode
# so that this runs on the older perl. This is now fixed in the
# CVS version of autoconf.
sed 's/\(mkdir.*\)/\1, 0755/' bin/autoreconf.in >
chmod --reference bin/autoreconf.in bin/autoreconf.in.new
touch --reference bin/autoreconf.in bin/autoreconf.in.new
mv -f bin/autoreconf.in.new bin/autoreconf.in
Perhaps that will help.
> I'm also building perl from source to deal with compiling some of my
> own modules that have C code. I originally set things up this way
> to handle problems on solaris where the compiler used to build perl
> was no longer available so compiling some modules failed. I tried
> the PerlGcc module but didn't have any luck.
Yes. You would need the same build environment for the modules as for
the original perl. Good luck!