php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #35288 iconv() function defined as libiconv()
Submitted: 2005-11-19 05:16 UTC Modified: 2006-06-30 15:14 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: webmaster at negeta dot com Assigned: moriyoshi
Status: Closed Package: ICONV related
PHP Version: 5CVS-2005-12-13 OS: FreeBSD 5.4
Private report: No CVE-ID:
 [2005-11-19 05:16 UTC] webmaster at negeta dot com
Description:
------------
On FreeBSD, the function "iconv" is exist as "libiconv."
http://www.php.net/manual/en/function.iconv.php#47428

And it causes "Call to undefined function" error
when "make test."
http://marc.theaimsgroup.com/?l=php-qa&m=113219318201772&w=2

Please include a wrapper (wraps above difference)
to test scripts.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-11-19 12:17 UTC] tony2001@php.net
Where is iconv.h in your system?
I'm unable to reproduce it on FreeBSD and it's definitely NOT reproducible on other systems, do a short investigation yourself, please and provide some info about it.
 [2005-11-19 14:07 UTC] webmaster at negeta dot com
I installed iconv from /usr/ports/converters/libiconv.
iconv.h is found in /usr/local/include.
I can find "#define iconv libiconv" in it.
 [2005-11-19 14:28 UTC] tony2001@php.net
Can't reproduce.
# ./sapi/cli/php -r 'iconv();'

Warning: iconv() expects exactly 3 parameters, 0 given in Command line code on line 1
# uname -r
5.4-STABLE
 [2005-11-19 17:55 UTC] webmaster at negeta dot com
I found how this problem occurs on my env.

0. C function "iconv" is exist, and "libiconv" is not.
1. configure detects "#define HAVE_ICONV 1"
  and HAVE_LIBICONV is not defined.
2. "#define iconv libiconv" in /usr/local/include/iconv.h line 80.
3. "#undef iconv" is not execute in ext/iconv/iconv.c line 55.
4. `libiconv' links to php_if_iconv in ext/iconv/iconv.c line 68. PHP function "libiconv" is created.
 [2005-11-19 21:37 UTC] iliaa@php.net
Try the following patch:
http://bb.prohost.org/patch/iconv.txt
 [2005-11-19 21:41 UTC] iliaa@php.net
Also, is HAVE_BSD_ICONV defined on your system?
 [2005-11-20 11:32 UTC] webmaster at negeta dot com
Only HAVE_ICONV is exist in my system.

Thank you for your patch, but it is not solve the problem.
This patch is not undef `iconv' when HAVE_LIBICONV is not defined.

As a test, I deleted first "#ifdef HAVE_LIBICONV" and "#endif",
it force undef 'iconv', and problem was not reproduce.
But I can't estimate about side-effect on other system.
 [2005-11-21 05:35 UTC] webmaster at negeta dot com
> 0. C function "iconv" is exist, and "libiconv" is not.
It's not correct and my mistake.
Both functions are available in my system.

Please check "libiconv" before checking "iconv."
Then HAVE_ICONV and HAVE_LIBICONV are defined by configure,
and the problem is not reproduce in my system.

Please commit this patch if it looks like good.
http://www.negeta.com/misc/acinclude.m4.patch
 [2005-11-21 16:06 UTC] sniper@php.net
What was the configure line used? 
And where exactly is iconv AND libiconv defined in your system? Do you have 2 different implementations installed under same prefix? If you do, this is not PHP bug and not possible to solve with that patch.
 [2005-11-21 17:49 UTC] webmaster at negeta dot com
I ran "./configure"

I only installed libiconv-1.9.2 from FreeBSD ports 'converters/libiconv.'

libiconv has C function "iconv" in 'lib/iconv.c', 
and alias name "libiconv" is defined in 'include/iconv.h.'
And a program can use "iconv" as "libiconv."

'configure' detects function "iconv" first.
And it detects "libiconv" when "iconv" was not found.
And HAVE_ICONV is defined and HAVE_LIBICONV is not defined.

When 'ext/iconv/iconv.c :line 68' is compiled,
PHP_NAMED_FE(iconv,php_if_iconv, ...
is understood as
PHP_NAMED_FE(libiconv,php_if_iconv, ...
by compiler. Because
#ifdef HAVE_LIBICONV
#undef iconv
#endif
skips undefine "iconv."

To solve this, I thought that HAVE_LIBICONV is necessary.
I read acinclude.m4, and found the order of "iconv" and "libiconv."

If 'configure' detect "libiconv" first,
then it will define HAVE_ICONV and HAVE_LIBICONV.
And if system has only "iconv", then it will not define HAVE_LIBICONV.

Maybe Linux system is not influenced by this problem.
Because these system has iconv of glibc, and there is no "libiconv."
 [2005-11-23 09:29 UTC] sniper@php.net
So you didn't read the comment above those checks?
Try removing that libiconv you installed and try again.
And make sure the installation of libiconv did NOT write over the system iconv.h !!!

 [2005-11-23 13:51 UTC] webmaster at negeta dot com
FreeBSD base system has no iconv library
which is usable by other executable.
FreeBSD does not contain the glibc,
and libiconv.so is not installed in base system.

I found '/usr/include/sys/iconv.h',
but it is used by some kernel modules.
Conflict will not occur because PHP does not
include "sys/iconv.h."

I removed libiconv and ran './configure',
then following error occured:

% tail -15 config.log
configure:19817: gcc -o conftest -g -O2   -R/usr/local/lib -L/usr/local/lib conftest.c

         -lm  -lxml2 -lz -liconv -lm 1>&5
/usr/bin/ld: cannot find -liconv
configure: failed program was:
#line 19806 "configure"
#include "confdefs.h"


    char xmlInitParser();
    int main() {
      xmlInitParser();
      return 0;
    }
 [2005-12-01 13:04 UTC] webmaster at negeta dot com
I specified the path of iconv explicitly.
I ran './configure --with-iconv=/usr/local',
and HAVE_LIBICONV was defined.
'libiconv' comes before 'iconv' when the path is specified.
But above priority is inverted when the path is not specified.
I was able to avoid this problem by using this difference.

I hope 'libiconv' comes before 'iconv' automatically
on the system that has both functions.
But, I will back out this problem if this difference
was designed for changing priority of them manually.
 [2005-12-06 23:01 UTC] sniper@php.net
Assigned to the person who broke it.
 [2005-12-07 11:56 UTC] moriyoshi@php.net
That's expected behaviour. I did not break anything. Rather, it would never detect the correct header if with --with-iconv before I fixed.


 [2005-12-07 12:01 UTC] tony2001@php.net
Since when having libiconv() instead of iconv() is expected behaviour?
 [2005-12-10 01:28 UTC] webmaster at negeta dot com
I found more basal things which cause this problem.
configure checks iconv in libc first.
But '-liconv' is added to compile option.
My system does not have iconv in libc , but it is found.
My system should find 'libiconv' in configure:44354.

-- output
checking for iconv support... yes
checking for iconv... yes

-- config.log
configure:44060: checking for iconv support
configure:44122: checking for iconv
configure:44150: gcc -o conftest -g -O2   -R/usr/local/lib -L/usr/local/lib conftest.c -lm  -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm 1>&5
 [2005-12-11 23:47 UTC] moriyoshi@php.net
Well, then are you *really* sure that the userland function named libiconv() is defined instead of iconv() in your build and that's the case?

Regarding the issues you call "more basal things", -liconv is appended to resolve libxml2 dependency there and so it's not a problem in the iconv extension.

You always need to specify --with-iconv=[PREFIX] when the libc doesn't have an iconv implementation nor no alternative can be found in the default header search path (supposedly /usr/include).





 [2005-12-12 13:29 UTC] webmaster at negeta dot com
I don't disagree that -lxml2 and -liconv are necessary for build iconv extension.
I said "compile" as "compile configure:44150", and paste its log.
It only checks iconv() in the libc.
I think -liconv shouldn't exist here,
because it make to link to iconv library.

I understand the searching order as follows:
1. iconv() in the libc.
2. libiconv() in the libc.
3. libiconv() in the userland.
4. iconv() in the userland.
Because acinclude.m4 says
"Check libc first if no path is provided in --with-iconv."
Is this searching order wrong?

My system has libiconv() and iconv() in the userland.
(libiconv() is an alias of iconv().)
I think following behavior is correct:
1. and 2. fail, and 3. succeeds.
 [2005-12-13 17:36 UTC] sniper@php.net
See also bug #35554

 [2006-01-01 13:57 UTC] webmaster at negeta dot com
I confirmed that the patch solves this problem.
Thanks!
 [2006-01-02 12:49 UTC] nlopess@php.net
I've made a little update to the patch:
 * use PHP_ADD_LIBRARY_WITH_PATH, instead of PHP_ADD_LIBRARY and PHP_ADD_LIBPATH
 * use $PHP_LIBDIR

BTW, this patch also fixes bug #33141.
 [2006-01-03 14:21 UTC] sniper@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 [2006-06-30 10:59 UTC] yunosh@php.net
This seems to happen again, compiling PHP 5.1.2 on FreeBSD 4.11. If I understand the comments correctly, configure should work out of the box with the applied patches, right? I need to provide the path to libiconv though, otherwise iconv() will be libiconv() in the in iconv extension.
 [2006-06-30 15:14 UTC] nlopess@php.net
yunosh: yes it was supposed to work, at least last time I compiled PHP on a Solaris box it was working.
Contact me if you need help debugging the problem.
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Sat Apr 19 19:02:15 2014 UTC