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

go to bug id or search bugs for

Bug #15788 microtime.c compile failure
Submitted: 2002-02-28 13:03 UTC Modified: 2002-02-28 13:40 UTC
From: whit at transpect dot com Assigned:
Status: Not a bug Package: Compile Failure
PHP Version: 4.1.2 OS: Red Hat 6.0 (modified)
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: whit at transpect dot com
New email:
PHP Version: OS:

 

 [2002-02-28 13:03 UTC] whit at transpect dot com 
Yes, I know this bug was marked "bogus" before. And I know 
the FAQ says to make sure your symlink is right. But with 
the symlink set right, using kernel 2.4.16 (built from the 
tar), compilation chokes on this. This is not a good thing 
when you have a bunch of people trying to upgrade because 
of the security issue.

(The symlink:
/usr/include# ls -l linux
lrwxrwxrwx    1 root     root           26 May  2  2001 
linux -> ../src/linux/include/linux/)

This is using gcc version 2.95.3 20010315 (release), also 
built from tar. Tried building the most recent version of 
glibc, but installing that was a serious mistake - 
breaking gcc among other things (if you make that mistake 
and have to revert to backup, be sure to restore or 
rebuild ld.so.cache first, without including it's files in 
/usr/local/include in ld.so.conf).

Please let me suggest that the PHP team would better 
always check against compiles of recent kernels.

On further attempt, the fix mentioned in the comments in 
the FAQ, of commenting lines in microtime.c as follows:

/* #ifdef HAVE_SYS_RESOURCE_H */
#include <sys/resource.h>
/* #endif */

does work (although I've also reverted to gcc-2.7.2.3 
since the glibc fiasco still has an afteraffect). So this 
is a bug in PHP, not in the user's system (unless you want 
to argue that kernel 2.4.16 has a bug here). Please fix 
it. And please correct the FAQ build section to remove the 
bogus advice that the user's symlinks or glibc version are 
what needs to be fixed.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-02-28 13:17 UTC] jimw@php.net 
the faq is (was, after the recent checkin) wrong. /usr/include/linux should never be a symlink to kernel sources. this has been well-discussed on various linux mailing lists. if your system has symlinks from /usr/include to the kernel source tree, it is broken.
 [2002-02-28 13:40 UTC] whit at transpect dot com 
If my system was truly broken, then editing the 
microtime.c file would not allow PHP to compile okay. 
Further, well up into the 4.x series PHP compiled fine on 
this same system. Expecting people to follow the Linux 
mailing lists for changes in the weight of opinion on 
whether Red Hat set up the 6.0 filesystem right, as 
compared to fixing PHP sources so that HAVE_SYS_RESOURCE_H 
is properly defined _even for systems like Red Hat 6.0, or 
the Slackware versions where PHP compilation presents a 
similar problem_ is the correct, right, decent and 
friendly thing to do. Short of that, the FAQ should 
present a either links to or a full description of the 
particular revision of the file system standard the PHP is 
unnecessarily trying to enforce. But the best solution is 
to make PHP compile successfully whether or not 
/usr/include is set up according to the latest fashion.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 24 01:00:02 2025 UTC