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.

I installed iconv from /usr/ports/converters/libiconv.
iconv.h is found in /usr/local/include.
I can find "#define iconv libiconv" in it.

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

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.

Try the following patch:
http://bb.prohost.org/patch/iconv.txt

Also, is HAVE_BSD_ICONV defined on your system?

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.

> 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

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.

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."

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 !!!

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;
    }

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.

Assigned to the person who broke it.

That's expected behaviour. I did not break anything. Rather, it would never detect the correct header if with --with-iconv before I fixed.

Since when having libiconv() instead of iconv() is expected behaviour?

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

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).

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.

See also bug #35554

Patch: http://mega.ist.utl.pt/~ncpl/php_libiconv_solaris.txt

Explanation:
http://news.php.net/php.internals/21360

I confirmed that the patch solves this problem.
Thanks!

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.

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.

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.

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.