Don't mind the type on the 1st description line - it's php 5.2.0 not 5.0.2 :)

What kind of iconv implementation is installed on your machine?
What do you see with `cat main/php_config.h | grep ICONV` ?

I tried with both glibc and libiconv-1.9.2; same result. Also when trying with '--with-iconv=/root/libiconv-1.9.2/lib/.libs/' php -i still reports using glibc.

cat main/php_config.h | grep ICONV
#define HAVE_LIBICONV 1
/* #undef HAVE_GICONV_H */
#define HAVE_LIBICONV 1
#define HAVE_ICONV 1
#define PHP_ICONV_IMPL "glibc"
/* #undef HAVE_BSD_ICONV */
#define PHP_ICONV_IMPL "glibc"
#define HAVE_GLIBC_ICONV 1
#define PHP_ICONV_IMPL "glibc"
#define ICONV_SUPPORTS_ERRNO 1
#define ICONV_SUPPORTS_ERRNO 1
#define ICONV_SUPPORTS_ERRNO 1
#define PHP_ICONV_H_PATH </usr/local/include/iconv.h>
/* #undef COMPILE_DL_ICONV */
#define HAVE_LIBICONV 1
/* #undef HAVE_GICONV_H */
#define HAVE_LIBICONV 1
#define HAVE_ICONV 1

Well, it looks like for some reason you have BOTH glibc and libiconv installed, and that is expected to cause problems.
And this: --with-iconv=/root/libiconv-1.9.2/lib/.libs/ is completely wrong.
Each time when configure expects <DIR>, it expects installation prefix, i.e. the value of --prefix=<DIR> used when configuring the library.
Please uninstall libiconv (you don't need it as long as you're using Linux, as you have glibc), remove config.cache and try again without the value for --with-iconv option.

Problem is, glibc implementation of iconv() seems to miss out on //TRANSLIT, that's why I'm trying to use libiconv. Is there any chance php will work with libiconv?

Sure. Install it properly into separate location and specify its prefix in configure.

Done:
Installed libiconv 1.9 in /opt/iconv

rm config.cache

'./configure' '--prefix=/usr' '--disable-static' '--with-apxs=/usr/local/apache/bin/apxs' '--sysconfdir=/etc' '--enable-discard-path' '--with-config-file-path=/etc/apache' '--with-openssl' '--enable-bcmath' '--with-bz2' '--with-pic' '--enable-calendar' '--enable-ctype' '--with-gdbm' '--with-imap-ssl=/tmp/pine4.58/imap/c-client' '--with-imap=/tmp/pine4.58/imap/c-client' '--enable-dbase' '--enable-ftp' '--with-iconv=/opt/iconv' '--with-exif' '--with-gd' '--enable-gd-native-ttf' '--with-jpeg-dir=/usr' '--with-png' '--with-gmp' '--with-xml=shared,/usr' '--with-gettext=shared,/usr' '--enable-trans-sid' '--enable-shmop' '--enable-sockets' '--with-regex=php' '--enable-sysvsem' '--enable-sysvshm' '--enable-yp' '--enable-memory-limit' '--with-tsrm-pthreads' '--enable-shared' '--disable-debug' '--with-zlib=/usr' '--with-kerberos' '--with-mysql' '--with-iconv-dir=/opt/iconv'

still the same result, iconv() undefined... also from what I can make of ./configure, it will search for glibc iconv and if found it will use it regardless of --with-iconv= value? And anyway, the problem was there before installing libiconv, when there was only glibc... it still gave undefined function for iconv.

Update: I just compiled php 5.0.4 with exactly the same options and it works, I also have an 5.1.2 running with iconv, so I think the problem appeared somewhere between 5.1.2 and 5.2.0

Update 2: CentOs 3.8 with php 5.1.2 and iconv() scripts working... compiled 5.2.0, inconv() undefined!

Please read my previous message.

I did read it, but it didn't help alot, I had 2 different servers that were running php 5.0.4 and 5.1.2 and iconv() worked fine, now I have 2 servers with 5.2.0 and no iconv... well, don't mind me, I'll just go back to 5.1.2 and wait until the bug gets fixed.

There is nothing to fix, except for a headers mess in your system. And I told you exactly how to do it.
Please install libiconv to a separate location, remove config.cache and rebuild PHP.

No feedback was provided for this bug for over a week, 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".

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.