php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #26258 CLI Build Failure With XSLT
Submitted: 2003-11-14 23:15 UTC Modified: 2003-11-17 17:49 UTC
From: nathan@php.net Assigned:
Status: Not a bug Package: XSLT related
PHP Version: 4.3.5-dev (Latest Snap) OS: Linux 2.4.20
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: nathan@php.net
New email:
PHP Version: OS:

 

 [2003-11-14 23:15 UTC] nathan@php.net
Description:
------------
Build fails. This is against Apache with CLI Build as well by default. After adjusting, and making --enable-cli become --disable-cli --disable-pear the build is fine. And using a CLI Build only fails as expected from previous results.

This configure line was perfect, until adding --enable-xslt --with-xslt-sablot=... --with-expat-dir=...

The previous build was this exact line with 4.3.4RC3, and this failure occured during an upgrade to 4.3.4 with xslt.

Reproduce code:
---------------
./configure --prefix=/usr/local/php434rc3 --with-apxs=/usr/local/apache/bin/apxs --with-mysql --enable-cli --disable-cgi --with-zlib --with-bz2 --enable-calendar --enable-exif --enable-ftp --with-gd --with-jpeg-dir=/usr/local/libjpeg --with-freetype-dir=/usr/local/freetype2 --with-iconv --enable-sockets --with-curl=/usr --with-mcrypt=/usr --with-cpdflib --with-srm=/usr/local/srm --enable-xslt --with-xslt-sablot=/usr/local/sablot --with-expat-dir=/usr/local/expat

Expected result:
----------------
Successful Build.

Actual result:
--------------
ext/mysql/libmysql/my_tempnam.lo: In function `my_tempnam':
/home/src/php-4.3.4/ext/mysql/libmysql/my_tempnam.c:115: the use of `tempnam' is dangerous, better use `mkstemp'
/usr/local/sablot/lib/libsablot.so: undefined reference to `operator new[](unsigned)'
/usr/local/sablot/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
/usr/local/sablot/lib/libsablot.so: undefined reference to `operator delete(void*)'
/usr/local/sablot/lib/libsablot.so: undefined reference to `__gxx_personality_v0'
/usr/local/sablot/lib/libsablot.so: undefined reference to `__cxa_pure_virtual'
/usr/local/sablot/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__class_type_info'
/usr/local/sablot/lib/libsablot.so: undefined reference to `operator delete[](void*)'
/usr/local/sablot/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info'
/usr/local/sablot/lib/libsablot.so: undefined reference to `operator new(unsigned)'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-11-15 21:11 UTC] nathan@php.net
Checked the CVS version as well. Same error.
 [2003-11-15 21:44 UTC] nathan@php.net
http://www.php.net/xslt - User Notes

maximo AT migliari DOT com
20-Oct-2003 10:14 

If you are getting undefined references errors with regards to Sablotron while compiling PHP, make sure you export LDFLAGS in your environment to contain -lstdc++

As someone suggested earlier, this must be done, however, for me, it did not work declaring it before the configure statement, or editing the Makefile after configuring and inserting it there.

The only way it worked for me was exporting the variable to the environment.

If you use the Bash shell, then you do this as follows:
export LDFLAGS=-lstdc++

If you use the Csh shell, then you do this as follows:
setenv LDFLAGS=-lstdc++

you can then verify if it went through using the env command.

What this does is tell the configure script to specify the Makefile not to use libtool as the linker, but use lstdc++ as a substitute.  Apparently libtool is in a not-so-great version at the moment, and until they come up with version 1.5, we will have to compile PHP with Sablotron this way (on some systems)
 [2003-11-17 17:49 UTC] sniper@php.net
Try searching the bug database before opening new reports about same issue..

 [2004-06-15 00:41 UTC] aemadrid at hyperxmedia dot com
Adding the environment variables on Fedora Core I with PHP 4.3.7 does not solve the problem. I exported the environment variables, make clean, ./configure, make and got the same errors. And I have tried different variations from different bugs reports of the environment variables line and it did not work a single time.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Dec 26 18:01:31 2024 UTC