What is the status of bringing PHP build process up to current
automake/autoconf/libtool versions?...
Gentoo doesn't even have a libtool 1.4.x available, afaict...
I've down-graded automake and autoconf okay, but then I can't even
emerge wget to try and download libtool from source because emerge
wget requires autoconf more recent...
Guess I'll try hacking away with symlinks and whatnot.
Kind of a PITA...
I realize there must be some reason for all this, but it seems awfully
creaky to this naive user.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Richard Lynch wrote:
What is the status of bringing PHP build process up to current
automake/autoconf/libtool versions?...Gentoo doesn't even have a libtool 1.4.x available, afaict...
I've down-graded automake and autoconf okay, but then I can't even
emerge wget to try and download libtool from source because emerge
wget requires autoconf more recent...Guess I'll try hacking away with symlinks and whatnot.
Kind of a PITA...
I realize there must be some reason for all this, but it seems awfully
creaky to this naive user.
Or you could try simply using the current versions. They work fine.
-Rasmus
Richard Lynch wrote:
What is the status of bringing PHP build process up to current
automake/autoconf/libtool versions?...
Or you could try simply using the current versions. They work fine.
Yes, they all fail equally well. :-)
[see next email]
So it's a documentation issue?
Or are those versions required under some Operating Systems?
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Richard Lynch wrote:
What is the status of bringing PHP build process up to current
automake/autoconf/libtool versions?...Or you could try simply using the current versions. They work fine.
Yes, they all fail equally well. :-)
I also use gentoo and the only thing I had to downgrade was flex (<2.5.30)..
Everything else works well.
Nuno
Richard Lynch wrote:
What is the status of bringing PHP build process up to current
automake/autoconf/libtool versions?...Or you could try simply using the current versions. They work
fine.Yes, they all fail equally well. :-)
I also use gentoo and the only thing I had to downgrade was flex
(<2.5.30)..
Everything else works well.
Nuno
Downgrading flex to 2.5.4a-r6...
seems to have fixed the issue.
I'm running make test right now :-)
Thanks all!!!
PS
I've also edited the but with a request to make it a Documentation
Fix, rather than a bug.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
What about adding the files generated by flex to CVS? Most people don't need
to regenerate those files anyway, and this way they could keep the newer
version of flex on their machine.
Downgrading flex to 2.5.4a-r6...
seems to have fixed the issue.
I'm running make test right now :-)
Thanks all!!!
PS
I've also edited the but with a request to make it a Documentation
Fix, rather than a bug.
What about adding the files generated by flex to CVS? Most people don't need
to regenerate those files anyway, and this way they could keep the newer
version of flex on their machine.
Most people don't use CVS, they use a) the releases b) snapshots.
The only group that needs CVS are the developers.
The snapshots are generated every other hour for a reason.
-Hannes
Downgrading flex to 2.5.4a-r6...
seems to have fixed the issue.
I'm running make test right now :-)
Thanks all!!!
PS
I've also edited the but with a request to make it a Documentation
Fix, rather than a bug.
I sure hope this isn't something particularly bone-headed...
Meanwhile, what made me think that I was screwing up buildconf is
actually not related to any particular version of
automake/autoconf/libtool at all, as I get the same thing with all
combinations readily available under Gentoo, as well as using the
documented versions, so I've opened a bug report:
And, actually, as far as I can tell, having no libtool at all, for
that matter.
I forgot to symlink /usr/bin/libtool to /usr/local/bin/libtool after
installing 1.4.3 from source...
I guess libtool comes into the picture later in the process than I am
getting.
http://bugs.php.net/bug.php?id=42041
Short version:
cvs co -r PHP_5_2
./buildconf
./configure
--enable-fastcgi
--enable-debug
--with-pgsql
--disable-xml
--disable-libxml
--disable-simplexml
--disable-xmlreader
--disable-exmlwriter
--disable-dom
--without-pear
make
zend_language_scanner.c: No such file or directory
Google turned up a bug from several distros allegedly fixed in
4.mumble, but the bugs.php.net ticket was closed due to no feedback,
so I'm not sure it really got fixed.
I'm hoping my report might be detailed enough to lead somebody to a
real resolution... :-)
I'm guessing that insisting on not having all the XML stuff in there
is the issue?...
Guess I'll try to install libxml tomorrow.
Or maybe I want libxml2?
I dunno.
Hopefully some sleep will clarify that one.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Richard Lynch wrote:
I sure hope this isn't something particularly bone-headed...
Meanwhile, what made me think that I was screwing up buildconf is
actually not related to any particular version of
automake/autoconf/libtool at all, as I get the same thing with all
combinations readily available under Gentoo, as well as using the
documented versions, so I've opened a bug report:And, actually, as far as I can tell, having no libtool at all, for
that matter.I forgot to symlink /usr/bin/libtool to /usr/local/bin/libtool after
installing 1.4.3 from source...I guess libtool comes into the picture later in the process than I am
getting.http://bugs.php.net/bug.php?id=42041
Short version:
cvs co -r PHP_5_2
./buildconf
./configure
--enable-fastcgi
--enable-debug
--with-pgsql
--disable-xml
--disable-libxml
--disable-simplexml
--disable-xmlreader
--disable-exmlwriter
--disable-dom
--without-pearmake
zend_language_scanner.c: No such file or directory
Google turned up a bug from several distros allegedly fixed in
4.mumble, but the bugs.php.net ticket was closed due to no feedback,
so I'm not sure it really got fixed.I'm hoping my report might be detailed enough to lead somebody to a
real resolution... :-)I'm guessing that insisting on not having all the XML stuff in there
is the issue?...Guess I'll try to install libxml tomorrow.
Or maybe I want libxml2?
I don't see how this could possibly have anything to do with libxml.
zend_language_scanner.c is generated by flex from zend_language_scanner.l
Your top-level Makefile should have a line that looks something like this:
/Users/rasmus/php52/Zend/zend_language_scanner.c:
/Users/rasmus/php52/Zend/zend_language_scanner.l
@$(LEX) -Pzend -S/Users/rasmus/php52/Zend/flex.skl -o$@ -i
/Users/rasmus/php52/Zend/zend_language_scanner.l
And at the top of the Makefile you should see LEX=flex
-Rasmus
I don't see how this could possibly have anything to do with libxml.
Probably not.
It's just that I've never tried to not have libxml, and it always
worked before.
zend_language_scanner.c is generated by flex from
zend_language_scanner.lYour top-level Makefile should have a line that looks something like
this:/Users/rasmus/php52/Zend/zend_language_scanner.c:
/Users/rasmus/php52/Zend/zend_language_scanner.l
@$(LEX) -Pzend -S/Users/rasmus/php52/Zend/flex.skl -o$@ -i
/Users/rasmus/php52/Zend/zend_language_scanner.l
Yep.
And at the top of the Makefile you should see LEX=flex
Nope.
LEX=exit 0;
I don't think that's right, eh?
How'd that get in there?
My flex is version 2.5.33
It's in /usr/bin/flex where it belongs, with all the other build
thingies.
I just emerege-d it like everything else, before I started.
[and before I tried to down-grade autoconf/automake/libtool]
If it helps, I did a grep "LEX=" *
to try to see where it snuck in.
acinclude.m4 and aclocal.m4 both have LEX="exit 0;"
So whatever built those probably isn't behaving.
config.cache has ac_cv_prog_LEX=${ac_cv_prog_LEX=flex}
configure has a whole bunch of lines, and I suspect typing them here
out of context won't help, so:
http://l-i-e.com/flex/configure
genfiles has:
STD='... LEX="flex -L"...
So how come it didn't find my flex?
I can hack the Makefile and move on, I guess, eh?
I'm starting to think I'm not being a complete bonehead.
(This time.)
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Is it normal that there's a couple hundred blank lines after the #!
/bin/sh first line?...
Made me think my FTP was very very broken for a minute there... :-v
Richard Lynch wrote:
I sure hope this isn't something particularly bone-headed...
Meanwhile, what made me think that I was screwing up buildconf is
actually not related to any particular version of
automake/autoconf/libtool at all, as I get the same thing with all
combinations readily available under Gentoo, as well as using the
documented versions, so I've opened a bug report:And, actually, as far as I can tell, having no libtool at all, for
that matter.I forgot to symlink /usr/bin/libtool to /usr/local/bin/libtool after
installing 1.4.3 from source...I guess libtool comes into the picture later in the process than I
am
getting.http://bugs.php.net/bug.php?id=42041
Short version:
cvs co -r PHP_5_2
./buildconf
./configure
--enable-fastcgi
--enable-debug
--with-pgsql
--disable-xml
--disable-libxml
--disable-simplexml
--disable-xmlreader
--disable-exmlwriter
--disable-dom
--without-pearmake
zend_language_scanner.c: No such file or directory
Google turned up a bug from several distros allegedly fixed in
4.mumble, but the bugs.php.net ticket was closed due to no feedback,
so I'm not sure it really got fixed.I'm hoping my report might be detailed enough to lead somebody to a
real resolution... :-)I'm guessing that insisting on not having all the XML stuff in there
is the issue?...Guess I'll try to install libxml tomorrow.
Or maybe I want libxml2?
I don't see how this could possibly have anything to do with libxml.
zend_language_scanner.c is generated by flex from
zend_language_scanner.lYour top-level Makefile should have a line that looks something like
this:/Users/rasmus/php52/Zend/zend_language_scanner.c:
/Users/rasmus/php52/Zend/zend_language_scanner.l
@$(LEX) -Pzend -S/Users/rasmus/php52/Zend/flex.skl -o$@ -i
/Users/rasmus/php52/Zend/zend_language_scanner.lAnd at the top of the Makefile you should see LEX=flex
-Rasmus
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
cvs co -r PHP_5_2
./buildconf
./configure
--enable-fastcgi
--enable-debug
--with-pgsql
--disable-xml
--disable-libxml
--disable-simplexml
--disable-xmlreader
--disable-exmlwriter
--disable-dom
--without-pearmake
zend_language_scanner.c: No such file or directory
I've had that exact same problem intermittently. Although there's a line in
Makefile that tries to build this file (by using bison), it seems
non-functional. Try "make Zend/ zend_language_scanner.c". In my experience,
this line returns without error but performs nothing.
If you manually execute the line in the Makefile (substituting the
appropriate variables), you'll have a zend_language_scanner.c and things
will be happy.
David
cvs co -r PHP_5_2
./buildconf
./configure
--enable-fastcgi
--enable-debug
--with-pgsql
--disable-xml
--disable-libxml
--disable-simplexml
--disable-xmlreader
--disable-exmlwriter
--disable-dom
--without-pearmake
zend_language_scanner.c: No such file or directory
I've had that exact same problem intermittently. Although there's a
line in
Makefile that tries to build this file (by using bison), it seems
non-functional. Try "make Zend/ zend_language_scanner.c". In my
experience,
this line returns without error but performs nothing.If you manually execute the line in the Makefile (substituting the
appropriate variables), you'll have a zend_language_scanner.c and
things
will be happy.
So I dink around with the Makefile a bit changing LEX=flex and LEX=
exit0; back and forth...
I get past the zend_language_scanner bit, I guess, and then it blows
up in my face with a whole bunch of errors about undefined reference
in spl_autoload, basic_functions, tokenizer, php_execute_script,
php_lint_script, zend_ini_parser, ...
The undefined references are to things like:
zend_destroy_file_handle
zend_file_handle_dtor
zif_highlight_file
highlight_file
zend_save_lexical_state
open_file_for_scanning
.
.
.
Yeah, maybe I shoulda left the Makefile alone... :-)
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
zend_language_scanner.c: No such file or directory
Found the issue (at least for me). The problem was that the version of flex
I had was 2.5.33, which is the latest version. However, 2.5.4 (an older
version, confusingly) is the only version supported by PHP (which is noted
in the documentation). 2.5.33 is not supported because backward
compatibility was broken. (http://bugs.php.net/bug.php?id=39895)
However, configure sees this as a warning and not a fatal error. But since
there's no copy of zend_language_scanner.c in CVS, this is in fact, fatal.
To make it even more difficult for people to figure out what's wrong, it
changes $(LEX) to "exit 0;" which of course makes the make of
zend_language_scanner.c succeed silently. I suppose if it returned anything
else, there would be problems if zend_language_scanner.l was accidentally
touched.
I think the moral of the story is probably to add zend_language_scanner.c to
CVS.
David
Short version: Fixed in CVS. :D
--Jani
zend_language_scanner.c: No such file or directory
Found the issue (at least for me). The problem was that the version of flex
I had was 2.5.33, which is the latest version. However, 2.5.4 (an older
version, confusingly) is the only version supported by PHP (which is noted
in the documentation). 2.5.33 is not supported because backward
compatibility was broken. (http://bugs.php.net/bug.php?id=39895)However, configure sees this as a warning and not a fatal error. But since
there's no copy of zend_language_scanner.c in CVS, this is in fact, fatal.
To make it even more difficult for people to figure out what's wrong, it
changes $(LEX) to "exit 0;" which of course makes the make of
zend_language_scanner.c succeed silently. I suppose if it returned anything
else, there would be problems if zend_language_scanner.l was accidentally
touched.I think the moral of the story is probably to add zend_language_scanner.c to
CVS.David
Short version: Fixed in CVS. :D
You folks rock!
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Kind of a PITA...
No problems here with automake-1.10 , autoconf-2.61 , libtool-1.5.22, bison-2.3.
the only oldie we had to keep is flex, as PHP buildsystem wont support
newer flex versions.
Kind of a PITA...
No problems here with automake-1.10 , autoconf-2.61 , libtool-1.5.22, bison-2.3.
the only oldie we had to keep is flex, as PHP buildsystem wont support
It's not the buildsystem that won't support old flex, it's the code that
is generated using it that doesn't.
And of those tools you mentioned only autoconf and bison are needed, the
rest isn't. You forgot to mention autoheader, but that of course comes
together with autoconf.
--Jani