I don't know this topic but according to: http://www.php.net/anoncvs
libtool 1.5 will not work. It also suggests older versions of the other tools although I'm unsure how much of that has to do with the page just not being updated. Regards, Philip On Sat, 14 Aug 2004, Ben Ramsey wrote: > They're installed according to however they are installed on Fedora Core 2. I > didn't install either one of them; they come with the system, afaik. > > [EMAIL PROTECTED] ramsey]$ aclocal --print-ac-dir > /usr/share/aclocal > [EMAIL PROTECTED] ramsey]$ ls -l /usr/share/aclocal/libtool* > -rw-r--r-- 1 root root 210301 Apr 11 22:01 /usr/share/aclocal/libtool.m4 > > So, you think I need to do a reinstall of autoconf/automake/libtool? Currently, > my system has the following installed as RPMs: > > [EMAIL PROTECTED] ramsey]$ rpm -qa | grep autoconf > autoconf213-2.13-8 > autoconf-2.59-3 > [EMAIL PROTECTED] ramsey]$ rpm -qa | grep automake > automake-1.8.3-1 > automake17-1.7.9-2 > automake16-1.6.3-2 > automake15-1.5-10 > automake14-1.4p6-9 > [EMAIL PROTECTED] ramsey]$ rpm -qa | grep libtool > libtool-libs-1.5.6-1 > libtool-libs13-1.3.5-9.1 > libtool-1.5.6-1 > > > > --- Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > > > Do this: > > > > aclocal --print-ac-dir > > > > This should show you the directory your various m4 macro files are in. > > The fact that the AC_PROG_LIBTOOL macro is shown as undefined is a sign > > that your autoconf/libtool stuff is completely misconfigured and don't > > know about each other. Did you install one from source and the other from > > a package or something? You should have a libtool.m4 file containing the > > AC_PROG_LIBTOOL macro in that ac-dir that aclocal knows about. > > > > So, basically, reinstall autoconf/automake/libtool correctly, and read up > > on aclocal. > > > > -Rasmus > > > > > > On Fri, 13 Aug 2004, Ben Ramsey wrote: > > > > > I've always had this problem, but I figured it was just something I had to > > > learn to live with. However, this time I decided to submit it to see if it > > > was worth passing along as a bug. > > > > > > Whenever I run ./buildconf, it tells me that I shouldn't run it in a > > release > > > package, so I try to run autoconf, which generates some errors, but a > > > configure file is still created, so I run ./configure, which always stops > > > with errors. Finally, I run ./buildconf --force and it throws out some > > > warnings but still creates a configure file that runs without any problems. > > > > > > Is this how it's supposed to work? > > > > > > I'm grabbing the source from CVS and compiling it on Fedora Core 2 with > > > autoconf verision 2.59 and libtool version 1.5.6. I had similar problems > > with > > > PHP-GTK 1.0.0, and Andrei had to change a few things around to get it > > updated > > > for my version of autoconf. > > > > > > At any rate, it's not like it won't build, but these errors always appear > > > quirky. > > > > > > Here's the output: > > > > > > [EMAIL PROTECTED] php_5_0_1]# ./buildconf > > > You should not run buildconf in a release package. > > > use buildconf --force to override this check. > > > [EMAIL PROTECTED] php_5_0_1]# autoconf > > > configure.in:147: warning: AC_PROG_LEX invoked multiple times > > > autoconf/programs.m4:438: AC_DECL_YYTEXT is expanded from... > > > configure.in:147: the top level > > > configure.in:77: error: possibly undefined macro: AC_MSG_ERROR > > > If this token and others are legitimate, please use m4_pattern_allow. > > > See the Autoconf documentation. > > > configure.in:138: error: possibly undefined macro: AC_MSG_CHECKING > > > configure.in:143: error: possibly undefined macro: AC_MSG_RESULT > > > configure.in:192: error: possibly undefined macro: AC_DEFINE > > > configure.in:453: error: possibly undefined macro: AC_TRY_LINK > > > configure.in:587: error: possibly undefined macro: PHP_AC_BROKEN_SPRINTF > > > configure.in:588: error: possibly undefined macro: PHP_AC_BROKEN_SNPRINTF > > > configure.in:692: error: possibly undefined macro: AC_DEFINE_UNQUOTED > > > configure.in:1170: error: possibly undefined macro: AC_PROG_LIBTOOL > > > [EMAIL PROTECTED] php_5_0_1]# ./configure [options omitted from this posting] > > > ./configure: line 42: syntax error near unexpected token `Running' > > > ./configure: line 42: `PHP_CONFIGURE_PART(Running system checks)' > > > [EMAIL PROTECTED] php_5_0_1]# ./buildconf --force > > > Forcing buildconf > > > using default Zend directory > > > buildconf: checking installation... > > > buildconf: autoconf version 2.59 (ok) > > > buildconf: Your version of autoconf likely contains buggy cache code. > > > Running cvsclean for you. > > > To avoid this, install autoconf-2.13 and automake-1.5. > > > buildconf: libtool version 1.5.6 (ok) > > > rebuilding aclocal.m4 > > > rebuilding configure > > > autoconf/programs.m4:438: AC_DECL_YYTEXT is expanded from... > > > configure.in:147: the top level > > > rebuilding acconfig.h > > > rebuilding main/php_config.h.in > > > autoheader: WARNING: Using auxiliary files such as `acconfig.h', > > > `config.h.bot' > > > autoheader: WARNING: and `config.h.top', to define templates for > > > `config.h.in' > > > autoheader: WARNING: is deprecated and discouraged. > > > autoheader: > > > autoheader: WARNING: Using the third argument of `AC_DEFINE' and > > > autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template > > without > > > autoheader: WARNING: `acconfig.h': > > > autoheader: > > > autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, > > > autoheader: [Define if a function `main' is needed.]) > > > autoheader: > > > autoheader: WARNING: More sophisticated templates can also be produced, see > > > > > the > > > autoheader: WARNING: documentation. > > > autoconf/programs.m4:438: AC_DECL_YYTEXT is expanded from... > > > configure.in:147: the top level > > > > > > > ===== > Regards, > Ben Ramsey > http://benramsey.com > > --------------------------------------------------- > http://www.phpcommunity.org/ > Open Source, Open Community > Visit for more information or to join the movement. > --------------------------------------------------- > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
