ID: 14483
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Critical
Bug Type: Compile Failure
Operating System: Mac OS X 10.1
PHP Version: 4.2.0-dev
Previous Comments:
------------------------------------------------------------------------
[2001-12-14 17:26:57] [EMAIL PROTECTED]
It's friday niiigghttt...
Doing:
grep -nrH "\*yytext" Zend/*
Yields:
-----
zend_ini_scanner.c:310:extern char *yytext;
zend_ini_scanner.c:496:char *yytext;
zend_language_scanner.c:305:extern char *yytext;
zend_language_scanner.c:2725:char *yytext;
-----
So:
pico -b -e -w +2725 zend_language_scanner.c
Comment out:
/* char *yytext; */
We are "money" because this is already declared as a extern in zend_ini_scanner or
whatever.
Now the compile completes, but everything is still hosed, because make install gives:
Making install in .
apxs -i -a -n php4 libs/libphp4.so
[activating module `php4' in /private/etc/httpd/httpd.conf]
cp libs/libphp4.so /usr/libexec/httpd/libphp4.so
cp: libs/libphp4.so: No such file or directory
apxs:Break: Command failed with rc=1
make[1]: *** [install-sapi] Error 1
make: *** [install-recursive] Error 1
Arg...
------------------------------------------------------------------------
[2001-12-14 16:59:25] [EMAIL PROTECTED]
Progress:
[Just downloaded and compiled the latest GNU autoconf, automake, and libtool]
After some further web research, most of it comes down to being a libtool issue, which
is covered here:
http://savannah.gnu.org/support/?func=detailsupport&support_id=100049&group_id=25
It all begins with replacing all instances of:
deplibs="$lib $deplibs"
with
if test "$libdir"; then
deplibs="$lib $deplibs"
fi
in ltmain.sh, and if configure has already been run, in libtool. There three
occurrences in ltmain.sh. The reason sh!t is multiply defined is because it's
multiply loaded. The above helps. This gets rid of the all of the multiple defined
error messages except:
-----
ld: multiple definitions of symbol _yytext
Zend/.libs/libZend.al(zend_language_scanner.lo) definition of _yytext in section
(__DATA,__common)
Zend/.libs/libZend.al(zend_ini_scanner.lo) definition of _yytext in section
(__DATA,__common)
/usr/bin/libtool: internal link edit command failed
make[1]: *** [libphp4.la] Error 1
make: *** [all-recursive] Error 1
-----
This is being attacked... more later... hopefully.
Also, I noticed main/php_config.h defines 'uint' even though /usr/include/sys/types.h
already has 'uint'. sys/types.h does't define ulong, thought.
In php_config.h 'uint' is defined twice, once right at the top and again on line 1836.
'ulong' is also defined, but that's OK. This does not hose anything, only it doesn't
allow use of the precompiled version of the system's unistd.p. Changing php_config.h,
starting at line 1836 (or near there):
from -----
/* Define to `unsigned int ' if <sys/types.h> does not define. */
#define uint unsigned int
/* Define to `unsigned long ' if <sys/types.h> does not define. */
#define ulong unsigned long
to -----
/* Define to `unsigned int ' if <sys/types.h> does not define. */
/* #define uint unsigned int */
/* Define to `unsigned long ' if <sys/types.h> does not define. */
#define ulong unsigned long
-----
and commenting out these two lines near the top, on line 9, so they appear as follows:
-----
/* #define uint unsigned int */
/* #define ulong unsigned long */
-----
Fixes this stuff. That leaves me with only the _yytext multiple defined errors, and
two or three cpp smart preprocessing warnings. Almost there...
------------------------------------------------------------------------
[2001-12-14 16:37:55] [EMAIL PROTECTED]
------------------------------------------------------------------------
[2001-12-13 07:18:30] [EMAIL PROTECTED]
Also a duplicate of bug 14154, which is a freakin' struggle of a bug.
------------------------------------------------------------------------
[2001-12-13 07:08:12] [EMAIL PROTECTED]
(NOTE: Duplicate of BUG 14256)
PHP 4.1.0 fails to compile on Mac OS X 10.1 (you probably already know this). This is
while building the Apache Module.
Notes:
- First scenario: attempting the run-of-the-mill compile fails once it gets to ld,
which throws out "-twolevel_namespace" warnings.
- Second scenario: Modifying (by adding "-flat_namespace") any presence of anything
that may seem like a compiler flag or linker flag in config_vars.mk, php_config.h,
libtool, etc., leads to a LARGE number of multiple definition errors that look like
this:
-----------
TSRM/.libs/libtsrm.al(tsrm_virtual_cwd.lo) definition of _virtual_utime in section
(__TEXT,__text)
TSRM/.libs/libtsrm.al(tsrm_virtual_cwd.lo) definition of _virtual_utime in section
(__TEXT,__text)
------------
These errors flow in large quantities (in pairs like above), right at the end of the
compile. The section (__TEXT,__text) part is always the same, but "(foo.lo)" changes
to what seems to be EVERY symbol that was compiled.
- Have downloaded latest snap from PHP.net (13 Dec 2001), and it still fails.
-Tried using latest libtool from GNU.org (1.4.2), with the same result.
-It seems like others are experiencing either of the scenarios above... since most
people know about the "-flat_namespace" flag, the try to deal, only to end up with the
large quantities of multiple symbol errors.
Hmm...
-Abner
------------------------------------------------------------------------
Edit this bug report at http://bugs.php.net/?id=14483&edit=1
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
