PHP 4.0 Bug #3636: recode library crashes AC_TRY_LINK() macro
| From: | kk at netuse dot de | Date: | Sat, 26 Feb 2000 17:57:18 +0000 |
| Subject: | PHP 4.0 Bug #3636: recode library crashes AC_TRY_LINK() macro | ||
| Groups: | php.dev | ||
| Request: | Send a blank email to php-dev+get-16053@lists.php.net to get a copy of this message | ||
From: kk@netuse.de
Operating system: Linux valiant 2.2.13 #1 Mon Nov 8 15:37:25 CET 1999 i686 unknown
PHP version: 4.0 Latest CVS (26/02/2000)
PHP Bug Type: Compile Failure
Bug description: recode library crashes AC_TRY_LINK() macro
I tried to port the GNU recode module to PHP4, but the
different build system makes that impossible.
The GNU recode library is faulty in the sense that it requires
the symbol program_name to be exported to link successfully.
In PHP3, the build process AC_TRY_LINK()ed every library
that was bind tested for individually, so that I could
AC_TRY_LINK([
char *program_name;
],[
recode_format_table();
],[],[
AC_MSG_ERROR(Cannot find librecode. Please install recode-3.5 or higher)])
for GNU recode and all other AC_TRY_LINK() for other
libraries were unaffected.
In PHP4, the build systems incrementally builds the library
configuration so that once the recode library has been found,
all subsequent AC_TRY_LINK() calls to all other libraries are
linked against GNU recode as well, which requires the above
program_name symbol. This symbol is not present in these
calls, though, so all subsequent AC_TRY_LINK() macros fail.
I request that the build system is changes to record the list of
libraries in a different, nonactive variable and only builds the
linker and library configuration in a final stage. Unless that is
changes porting the GNU recode module will be difficult.
The recode maintainer has been informed of the problem for
quite some time and has promised a fix of the library in a 3.6
release, which has not yet arrived, though.