php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #17604 Apache 2/MySQL/PHP4/Sablotron Will not compile
Submitted: 2002-06-05 03:33 UTC Modified: 2002-10-25 01:00 UTC
Votes:10
Avg. Score:4.2 ± 0.9
Reproduced:8 of 8 (100.0%)
Same Version:3 (37.5%)
Same OS:2 (25.0%)
From: kevin at kevinfries dot com Assigned:
Status: No Feedback Package: Compile Failure
PHP Version: 4.2.1 OS: Solaris 8 IA
Private report: No CVE-ID: None
View Developer Edit
 [2002-06-05 03:33 UTC] kevin at kevinfries dot com 
Platform Details:
P-II 400/384MB Ram
Solaris 8 IA
Apache 2.0.36  Options +Includes +FollowSymLinks
MySQL 3.23.49

I am trying to get this blessed server to compile and install.

Apache runs great, no problem there, CGIs work, SSI works, everything OK.  MySQL works.  I can run the mysqladmin and everything is fine.

I am trying to compile PHP with sablotron xslt extention, and expat.  sabcmd (version 0.90) runs fine from the command line against expat 1.95.2.  All installed in /usr/local/lib and /usr/local/bin.  If I give sabcmd a xslt file and a xml file on the commandline, I am bombarded with the html translation.  All is good.

Now, time to tie it all together:
I first tried:
CC=gcc ./configure --with-mysql=/usr/local/mysql --with-apxs2 --enable-xslt --with-xslt-sablot

it compiled linked and installed ok, but caused Apache to no longer startup due to linking errors in ld.so.  I asked about those the other day and go no response, so I am assuming nobody has any more ideas than I do about that one.

Then I thought, well if sablotron works from the command line, it must like the version of expat I am running, I bet PHP is linking with an old version.  Checked the output and sure enough, it is trying to link with a version that it has in the distro.  So, the next try was to tell PHP to just use the newer one installed in /usr/local/lib.  That should solve the ld.so problem.  Tried compile with:

CC=gcc ./configure --with-mysql=/usr/local/mysql --with-apxs2 --enable-xslt --with-xslt-sablot --with-expat-dir=/usr/local/lib

This version tells me that my version of expat is bad.
More specifically:
checking whether to enable XML support... yes
checking external libexpat install dir... yes
configure: error: not found. Please reinstall the expat distribution.

If I do a 'ls /usr/local/lib | grep expat' I get:
libexpat.a
libexpat.la
libexpat.so
libexpat.so.0
libexpat.so.0.1.0

I think I now have my problem.  Sablotron is working fine against the new expat, but PHP is not.  Got a bit of a chicken and egg here.  If I uninstall Sablotron, I can not install XSLT support because the required lib is missing.  If I compile against the current codebase, PHP chokes. 

If you like, compile again and send you the full configure and make output for either of my attempts.

Kevin Fries

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-06-05 03:36 UTC] kevin at kevinfries dot com 
Oops, sorry, coppied from my newsnet posting that got no response, and I forgot to reference the apache startup error that is referenced in this message:

Syntax error on line 230 of /usr/local/apache/conf/httpd.conf:
Cannot load /usr/local/apache/modules/libphp4.so into server: ld.so.1:
/usr/local/apache/bin/httpd: fatal: relocation error: file : symbol
_ZTVN10__cxxabiv120__si_class_type_infoE: referenced symbol not found
apachectl start: httpd could not be started
 [2002-06-05 20:27 UTC] kevin at kevinfries dot com 
Sablotron version 0.90

All I did was a standard:
./configure
make
make install

Nothing special
 [2002-06-16 05:34 UTC] pavel at gingerall dot cz 
It looks like traditional problem with linking the C++ library (what Sablotron is) and C code. This is rather the autoconf/libtool issue then sablotron's one. 

Sablotron itself doesn't require any other librraies then expat and libjs (when enabled, what is not the problem discussed).

An issue usually is, that gnu linker links additional 'magic' libraries to the executable file (not to the library file). This is typically named like libstdc++.

Problem is, that Sablotron can not guess these libraries, since they depend on the system and compiler used.

This is a known issue related to configuration tools, read libtool documentation and FAQs.

It is possible to check, waht libraries are linked to working sabcmd (use something like ldd from GNU's binutils) and set LDFLAGS='-lsomething' when configuring PHP.

Conclusion: may be I'm wrong, but problem described looks like one we meet from time to time. It is usually on platforms, where gnu tools are not the default (namely gnu ld is not the default linker). If I could do anything to kill this problem, I'd do it, but there are many people solving this problem with many libraries :(

The best solution (of bad ones) is to maintain good README file and list libraries needed for different platforms. We'd like to do it in our README, but we usually do not get the solution and platform set, we can use is limited.

Pavel 
(Sablotron maintainer)
 [2002-06-17 03:55 UTC] pavel at gingerall dot cz 
I'm sorry libstdc++ is nonsense. Sorry for this. Sablotron doesn't use the standard c++ libs. What is usually missing is something like lgcc. 

Take this comment as five beer voucher (valid in Prague only), for geek, who finds the appropriate library for given configuration :)
 [2002-06-17 04:05 UTC] pavel at gingerall dot cz 
-lgcc_s looks good (according to Kevin's recent comment)

Here is link to libtool documentation (no good news there)

<http://www.gnu.org/software/libtool/manual.html#C++%20libraries>
 [2002-06-17 04:21 UTC] pavel at gingerall dot cz 
One more link

<http://www.ucmb.ulb.ac.be/documents/libg++_2.7.1/g++FAQ_16.html>
 [2002-06-17 04:25 UTC] markonen@php.net 
I guess the right thing to do would be to use the 'g++' 
driver for linking when there's c++ code involved. 
Alternatively you can try the driver in verbose mode to see 
how it invokes ld (all the libs you need will be on the 
link line).

These libraries are, IIRC, platform and GCC version 
specific, so they cannot easily be added to PHP by default. 
So using g++ would be the preferred solution here.

And Kevin, for the love of God, upgrade to gcc 3.1.
 [2002-06-17 19:09 UTC] sniper@php.net 
If you didn't try it yet, try adding --enable-libgcc to your configure line (to be sure, use clean, fresh sources extracted from the latest snapshot tarball)

And if that doesn't work, try that LDFLAGS="-lgcc_s" 

--Jani
 [2002-06-18 04:32 UTC] markonen@php.net 
Kevin, could you try that last link again by hand, 
substituting g++ for gcc?

I want to get this fixed on the PHP side, and there's no 
way we can include stuff like libgcc_s by default.
 [2002-06-18 15:17 UTC] markonen@php.net 
Right. I didn't mean that, though. Could you try the last 
libtool line you pasted in your previous comment, but with 
gcc replaced with g++?

The one that begins with:


/bin/sh libtool --silent --mode=link gcc -export-dynamic 
...

and ends with all the errors.
 [2002-06-18 18:01 UTC] sniper@php.net 
I would guess that the g++ problem also breaks the configure
and the iconv checks fail. OTOH, you didn't specify
--with-iconv=/usr/local in your configure line either..

Check the config.log for the iconv checks.
 [2002-06-19 05:03 UTC] markonen@php.net 
Well, -liconv is missing from that link line, and according 
to your previous error, it was missing earlier as well. 

Linking with g++ seemed to solve all the C++ -related 
problems.

So, try to configure again with --with-iconv=/usr/local 
(but without specifying CC=g++ or anything). Then compile, 
and again replace gcc with g++ on the last link line.
 [2002-10-25 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri May 09 03:01:30 2025 UTC