Check the config.log for more detailed error message why the configure failed. And using that kind of workarounds is not very wise.

--Jani

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.

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

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

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

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.

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