ID:               16776
 Updated by:       [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
-Status:           Feedback
+Status:           Closed
 Bug Type:         Compile Failure
 Operating System: RedHat Linux 7.2
 PHP Version:      4.2.0
 New Comment:

And it should also be able to make coffee? :)

In some systems, the iconv is builtin to glibc.
So if you don't tell the path to --with-iconv it will first
look in glibc. Use --with-iconv with the path and it will
work. 

I have fixed the expat search in XSLT to look in /usr/local and /usr
for the libs and headers. (fix will be in 4.3.0 and hopefully also in
4.2.1)

--Jani



Previous Comments:
------------------------------------------------------------------------

[2002-04-30 13:09:44] [EMAIL PROTECTED]

My post of 24 Apr already contains the exact error message(s) from
config.log.  

But I've since found the solution: Even though I have expat installed
in standard library and include paths, for some reason I need to use
--with-expat-dir=/usr to explicitly direct it to look for expat in
/usr/include and /usr/lib.

Apparently the PHP configure still _does_ try to link to xmltok and
xmlparse libraries if it can't find libexpat.  And without the explicit
--with-expat-dir=/usr directive, for some reason it wasn't able to find
expat, so it was trying to link to xmltok and xmlparse and failing.

When I use --with-expat-dir=/usr, it successfully configures and
compiles.  The module still fails to load into apache, however, with
the following errors:
/usr/local/lib/libsablot.so: undefined reference to `libiconv_open'
/usr/local/lib/libsablot.so: undefined reference to `libiconv_close'
/usr/local/lib/libsablot.so: undefined reference to `libiconv'

The problem here is that I had an external libiconv installed, and
Sablotron was compiled to use that, but PHP was not linking in -liconv,
so libsablot was unable to find its iconv functions.  Removing the
external libiconv and recompiling Sablotron to use the libc iconv fixed
the problem.

I don't know whether these issues qualify as bugs, but they certainly
caused problems on my system.  It seems to me that PHP's configure
should have been able to find my expat in the usual paths without being
told where to look, and should also link in an external libiconv if
Sablotron is compiled to use it.

------------------------------------------------------------------------

[2002-04-29 15:19:36] [EMAIL PROTECTED]

No..don't install the old xmltok..stuff. The error message
given by PHP configure is misleading and has been fixed in CVS. These
old libraries are not even tried to be used anymore. So remove those
rpms! (expat is the same thing actually)

Also, in linux glibc, iconv functions are builtin.
So there is something else going wrong in configure time
which fails the iconv tests. Please try again after removing
those xmltok.. rpms. And check the config.log for the reason
WHY the check fails.

--Jani



------------------------------------------------------------------------

[2002-04-28 23:37:13] [EMAIL PROTECTED]

I have the RPM expat-1.95.2-1 installed, provides the library
libexpat.so.0.1.0, which is in my lib path.  Had no trouble at all
configuring and compiling Sablot-0.90.

In more searching just now I found the contrib RPM libxmltok-1.0-2 (and
libxmltok-devel-1.0.2), which provides the libraries libxmltok and
libxmlparse.  The file /usr/bin/xmlwf from this package conflicts with
/usr/bin/xmlwf from the expat package (way different file sizes, too),
but after forcing the package install anyway I was able to complete PHP
4.2.0 configure.  Then the make failed with:

/bin/sh /usr/local/src/php-4.2.0-module/libtool --silent --mode=link
gcc -I. -I/usr/local/src/php-4.2.0-module/
-I/usr/local/src/php-4.2.0-module/main
-I/usr/local/src/php-4.2.0-module
-I/usr/local/src/php-4.2.0-module/Zend
-I/usr/local/src/php-4.2.0-module/ext/mysql/libmysql
-I/usr/local/src/php-4.2.0-module/ext/xml/expat -I/usr/local/include 
-I/usr/local/src/php-4.2.0-module/TSRM -g -O2   -o php -export-dynamic 
      stub.lo libphp4.la 
/usr/local/lib/libsablot.so: undefined reference to `libiconv_open'
/usr/local/lib/libsablot.so: undefined reference to `libiconv_close'
/usr/local/lib/libsablot.so: undefined reference to
`XML_SetParamEntityParsing'
/usr/local/lib/libsablot.so: undefined reference to `libiconv'
collect2: ld returned 1 exit status
make[1]: *** [php] Error 1
make[1]: Leaving directory `/usr/local/src/php-4.2.0-module'
make: *** [all-recursive] Error 1

------------------------------------------------------------------------

[2002-04-24 19:33:28] [EMAIL PROTECTED]

Where is expat installed in your system?
Sablotron requires it..I had to grab some rpms to get
it even configure without bailing out.


------------------------------------------------------------------------

[2002-04-24 10:47:32] [EMAIL PROTECTED]

Here's the first failure in config.log:

[...]
configure:69992: checking for iconv                               
configure:70029: gcc -o conftest -g -O2 conftest.c \
-lxmltok -lxmlparse -lcrypt -lresolv -lm -ldl -lnsl \
-lresolv -lcrypt >&5
/usr/bin/ld: cannot find -lxmltok
collect2: ld returned 1 exit status
configure:70032: $? = 1
[snip test prog printout]
configure:70048: result: no
[...]

There are three more almost identical failures immediately following,
on these checks:
configure:70056: checking for libiconv
configure:70162: checking for libiconv in -liconv
configure:70230: checking for iconv in -liconv
In each case the error is the same: cannot find -lxmltok.

Also, the unwise workaround (which has seemed to work fine on 4.1.2 so
far) doesn't actually work on 4.2.0 - it allows the compile, but
attempting to start Apache with the module fails with undefined symbol
libiconv_open.

------------------------------------------------------------------------

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/16776

-- 
Edit this bug report at http://bugs.php.net/?id=16776&edit=1

Reply via email to