php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #38872 Error in Makefile - cannot generate global symbols for CLI interpreter
Submitted: 2006-09-18 20:44 UTC Modified: 2006-09-18 21:18 UTC
From: flconseil at yahoo dot fr Assigned:
Status: Not a bug Package: *Compile Issues
PHP Version: 5.1.6 OS: AIX 5.2
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: flconseil at yahoo dot fr
New email:
PHP Version: OS:

 

 [2006-09-18 20:44 UTC] flconseil at yahoo dot fr
Description:
------------
Before linking the 'php' CLI executable file, the symbol table is generated in the 'php.sym' file.

The command to generate the symbols and link the CLI interpreter is contained in the BUILD_CLI variable (in the Makefile). This string contains a 'sed' command to transform the '.lo' pathnames to their '.o' content, and this command is wrong in 5.1.6.

Reproduce code:
---------------
In 5.1.6, the sed command is :

sed 's/\([A-Za-z0-9_]*\)\.lo/\1.o/g'

, which just changes the '.lo' suffix to '.o'. It is wrong because the '.o' files are in the '.libs' subdirectory !

Expected result:
----------------
The correct syntax for the sed command should be the same as version 5.1.2 :

sed 's/\([A-Za-z0-9_]*\)\.lo/.libs\/\1.o/g'

(I just looked at versions 5.1.2 and 5.1.6. I don't know if 5.1.4 is correct or wrong)

Actual result:
--------------
When generating the 'php.sym' file, the 'nm' command receives wrong pathnames and does not output any symbol. As there is a pipe to 'awk', its return code of 1 does not cause the make process to stop (return code from awk is OK). So, the php interpreter is generated with and empty 'php.sym' file, which means that it does not export any gloabl symbol.

It works well until someone tries to load a shared extension. At this time, any call from the extension to the core code cannot be resolved by the runtime linker and the load fails.

I don't know if every extension calls some functions in the core but, on my configuration, it is the case, and none of them can be loaded. It starts with bcmath unable to resolve 'OnUpdateLong', and, then, every extension has some unresolved symbols.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-09-18 21:18 UTC] tony2001@php.net
It works perfectly fine here with GNU tools used.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 18:01:29 2024 UTC