php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #3636 recode library crashes AC_TRY_LINK() macro
Submitted: 2000-02-26 12:57 UTC Modified: 2000-02-29 08:11 UTC
From: kk at netuse dot de Assigned:
Status: Closed Package: Compile Failure
PHP Version: 4.0 Latest CVS (26/02/2000) OS: Linux valiant 2.2.13 #1 Mon Nov
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: kk at netuse dot de
New email:
PHP Version: OS:

 

 [2000-02-26 12:57 UTC] kk at netuse dot de 
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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-02-29 08:11 UTC] sas at cvs dot php dot net 
Yes, the current build system assumes that you are going to create a binary which will work, so linking against all of the libraries must always work.

This approach works (and works better than the approach you describe in numerous scenarios - we used something like that before), but it does not work always. 

It does not work, if a library expects the binary to export certain symbols.

This is solved in the current CVS with AC_ADD_LIBRARY_DEFER.
 
PHP Copyright © 2001-2026 The PHP Group
All rights reserved. 		Last updated: Wed Oct 14 02:00:01 2026 UTC