Bug #14483 Updated: -twolevel_namespace and multiple definitions errors
| From: | abner at criticalnexus dot com | Date: | Tue, 08 Jan 2002 20:47:01 +0000 |
| Subject: | Bug #14483 Updated: -twolevel_namespace and multiple definitions errors | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-76286@lists.php.net to get a copy of this message | ||
ID: 14483
User updated by: abner@criticalnexus.com
Reported By: abner@criticalnexus.com
Status: Critical
Bug Type: Compile Failure
Operating System: Mac OS X 10.1
PHP Version: 4.2.0-dev
New Comment:
A solution, that works, for now:
Thanks to http://www.entropy.ch/software/macosx/php/
(Marc Liyanage).
---------
NOTE 2: I was not able to get the build for PHP 4.1.0 to work correctly,
probably because of libtool issues. A helpful developer suggested
- running configure in the PHP 4.0.6 source tree
- modifying the resulting libtool script
- then configuring the PHP 4.1.0 sources
- copying the modified 4.0.6 libtool over to the 4.1.0 directory
- and finally running make
This did the trick for me. Here's the line that needs to be changed in
the 4.0.6 libtool script:
old: archive_cmds="\$CC -bundle -undefined suppress -o \$lib \$libobjs
\$deplibs \$linkopts"
new: archive_cmds="\$CC -flat_namespace -bundle -undefined suppress -o
\$lib \$libobjs \$deplibs \$linkopts"
--------- END
Hopefully this will help passers-by looking for assistance. It seems
like the old libtool (1.3.5?) was OK (except for the -flat_namespace
thing). It's this 1.4.2 that has caused the headache...
I have PHP 4.1.1 working using this shenanigan. No more typing
HTTP_POST_VARS and gratuitous global declarations! Bruhuhahaha...
Oh yeah, I can also say that bug ID 10686 (in datetime.c) has been fixed
and that behavior no longer appears in the mktime function... Booyah...
(http://bugs.php.net/bug.php?id=10686)
Previous Comments:
------------------------------------------------------------------------
[2001-12-16 18:25:22] sniper@php.net
That 'apxs' problem is actually the same bug in libtool as it is under
AIX.
------------------------------------------------------------------------
[2001-12-15 14:11:42] abner@criticalnexus.com
Are you talking about commenting out the "yytext"...
Is this a libtool bug?
Seems like somebody on AIX is having a similar problem.
http://bugs.php.net/bug.php?id=14245
In the Mac OS X situation, though... it seems to be a threefold
problem...
1. ltmain.sh (due to multiple symbol errors)
2. yytext issue
3. apxs issue
------------------------------------------------------------------------
[2001-12-15 07:33:10] derick@php.net
That commenting out should not be nessecairy, I have the same on my
system. The problem is something else...
Derick
------------------------------------------------------------------------
[2001-12-14 17:26:57] abner@criticalnexus.com
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] abner@criticalnexus.com
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...
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=14483
Edit this bug report at http://bugs.php.net/?id=14483&edit=1