Bug 181798 - Build failure: apxs:Error: Config file /var/tmp/php-root/etc/httpd/conf/httpd.conf not found
Build failure: apxs:Error: Config file /var/tmp/php-root/etc/httpd/conf/httpd...
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2006-02-16 12:47 EST by Graham Leggett
Modified: 2008-05-06 20:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-06 20:22:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Replacement patch for php-4.3.3-install.patch (2.22 KB, patch)
2006-02-19 18:23 EST, Graham Leggett
no flags Details | Diff

  None (edit)
Description Graham Leggett 2006-02-16 12:47:56 EST
While building a Fedora Development RPM of php-5.1.2-4.3 from source against the
ASF RPM of httpd v2.2.0, the build eventually bombs out at the end like so:

+ pushd build-apache
/usr/src/redhat/BUILD/php-5.1.2/build-apache /usr/src/redhat/BUILD/php-5.1.2
+ make install-sapi INSTALL_ROOT=/var/tmp/php-root
Installing PHP SAPI module:       apache2handler
/usr/lib/httpd/build/instdso.sh SH_LIBTOOL='/usr/lib/apr/build-1/libtool' libphp
5.la /var/tmp/php-root/usr/lib/httpd/modules
/usr/lib/apr/build-1/libtool --mode=install cp libphp5.la /var/tmp/php-root/usr/
cp .libs/libphp5.so /var/tmp/php-root/usr/lib/httpd/modules/libphp5.so
cp .libs/libphp5.lai /var/tmp/php-root/usr/lib/httpd/modules/libphp5.la
libtool: install: warning: remember to run `libtool --finish /usr/src/redhat/BUI
chmod 755 /var/tmp/php-root/usr/lib/httpd/modules/libphp5.so
apxs:Error: Config file /var/tmp/php-root/etc/httpd/conf/httpd.conf not found.
make: *** [install-sapi] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.93952 (%install)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.93952 (%install)

It seems the build wants to access the currently running httpd config file for
some reason, and it is looking for the file in the wrong place.
Comment 1 Joe Orton 2006-02-16 14:00:22 EST
Did you remove the patches we apply?
Comment 2 Graham Leggett 2006-02-16 17:02:21 EST

I am currently running through a build with the php-4.3.3-install.patch removed,
it takes a while (it only bombs at the end), will let you know.
Comment 3 Graham Leggett 2006-02-17 01:29:34 EST
Investigating further, it comes down to the followin g 3 lines of the spec file:

# Install the Apache module
pushd build-apache
make install-sapi INSTALL_ROOT=$RPM_BUILD_ROOT

It looks like the make install-sapi target expects to find a working httpd.conf
file, but with the change in build root this code breaks.

Will look further.
Comment 4 Graham Leggett 2006-02-17 01:45:01 EST
Inside the install-sapi target, the following line is run:

INSTALL_IT = $(mkinstalldirs) '$(INSTALL_ROOT)/usr/lib/httpd/modules' && $(mkins
talldirs) '$(INSTALL_ROOT)/etc/httpd/conf' && /usr/sbin/apxs -S LIBEXECDIR='$(IN
STALL_ROOT)/usr/lib/httpd/modules' -S SYSCONFDIR='$(INSTALL_ROOT)/etc/httpd/conf
' -i -a -n php5 libphp5.la

From looking at the docs for apxs, this line installs (-i) the module, and adds
(-a) the LoadModule statement to the httpd.conf file, the catch being that there
isn't an httpd.conf file, thus the failure.

Will check whether this will be accepted by apxs in httpd v2.0.x, while being
rejected by apxs in httpd v2.2.x.
Comment 5 Joe Orton 2006-02-17 04:07:59 EST
If the -install patch is applied, INSTALL_IT will not pass -a to apxs; read the
patch and see what it does.  You should only see the failure to find httpd.conf
if that patch has not been applied properly.
Comment 6 Graham Leggett 2006-02-19 15:18:48 EST
I have checked the original config.m4, and the patch is applied.

The output however remains from the unpatched version, as below (before the call
to INSTALL_IT in Makefile, I added an echo).

It looks like the attempt to run buildconf is not causing all build files to be

In addition, the sense of the "test -z" that is commented out by the patch means
that if the file httpd.conf does not exist (as in theory it wouldn't on a build
box with httpd installed but not configured) the build will work, but as soon as
the httpd.conf file does exist (eg on a live server, with php being built for it
as in this case) the build fails.

Because the "test -z" has not been completely removed by buildconf, the build
fails on a box where httpd.conf exists.

[root@chandler build-apache]# INSTALL_ROOT=/var/tmp/php-root/ make -e install-sapi
Installing PHP SAPI module:       apache2handler
echo /usr/src/redhat/BUILD/php-5.1.2/build/shtool mkdir -p
'/var/tmp/php-root//usr/lib/httpd/modules' &&
/usr/src/redhat/BUILD/php-5.1.2/build/shtool mkdir -p
'/var/tmp/php-root//etc/httpd/conf' && /usr/sbin/apxs -S
LIBEXECDIR='/var/tmp/php-root//usr/lib/httpd/modules' -S
SYSCONFDIR='/var/tmp/php-root//etc/httpd/conf' -i -a -n php5 libphp5.la
/usr/src/redhat/BUILD/php-5.1.2/build/shtool mkdir -p
/usr/lib/httpd/build/instdso.sh SH_LIBTOOL='/usr/lib/apr/build-1/libtool'
libphp5.la /var/tmp/php-root//usr/lib/httpd/modules
/usr/lib/apr/build-1/libtool --mode=install cp libphp5.la
cp .libs/libphp5.so /var/tmp/php-root//usr/lib/httpd/modules/libphp5.so
cp .libs/libphp5.lai /var/tmp/php-root//usr/lib/httpd/modules/libphp5.la
libtool: install: warning: remember to run `libtool --finish
chmod 755 /var/tmp/php-root//usr/lib/httpd/modules/libphp5.so
apxs:Error: Config file /var/tmp/php-root//etc/httpd/conf/httpd.conf not found.
make: *** [install-sapi] Error 1
Comment 7 Graham Leggett 2006-02-19 18:20:57 EST
Some more testing shows that the application of the install patch, even though
successful, does not show up in the generated Makefile during the build, which
still tries to "test -z".

Turns out there are 4 places where the "test -z" condition needs to be replaced,
so the current php-4.3.3-install.patch is wrong.

The attached patch attempts to fix the problems with the install patch, but yet
again, the build fails, and fails in exactly the same place.

I am beginning to suspect that the buildconf script is broken, will investigate
Comment 8 Graham Leggett 2006-02-19 18:23:18 EST
Created attachment 124871 [details]
Replacement patch for php-4.3.3-install.patch

Replace php-4.3.3-install.patch with this patch.
Comment 9 Graham Leggett 2006-02-20 02:03:12 EST
It seems that all attempts to patch the config.m4 files are for nothing:

[root@chandler php-5.1.2]# ls -al configure
-rwxr-xr-x  1 root root 2961879 Jan 11 08:25 configure

The configure script is not being regenerated by the RPM build.

Busy testing by adding "autoconf" after "buildconf --force" in the spec file.
Comment 10 Graham Leggett 2006-02-20 04:23:00 EST
Finally, the RPM builds.

To achieve this, you need to:

- Replace the php-4.3.3-install.patch with the attached patch

- Add a call to "autoconf" directory after "./buildconf --force" in the spec
file to force the rebuild of configure.
Comment 11 Joe Orton 2006-02-20 04:40:09 EST
You need to work out why buildconf is not rebuilding the configure script, that
works fine here.  It sounds like that is the only real issue you are hitting.
Comment 12 Graham Leggett 2006-02-20 04:54:48 EST
There are two issues.

The original php-4.3.3-install.patch fixed the broken "test -z" case in just one
of the four places the "test -z" appears.

The fix is to try and detect whether the SYSCONFDIR exists (prefixed with
INSTALL_ROOT, ie it won't exist in this case) rather than detecting whether
SYSCONFDIR is defined (I don't know of an instance where apxs can exist, but the
definition of SYSCONFDIR within apxs won't, making the test always false and
therefore pretty meaningless).

The attached patch fixes the tests, and makes the change in all four places.

Why buildconf isn't working is a separate bug, busy hunting that down.
Comment 13 Joe Orton 2006-02-20 05:13:13 EST
The other test -z cases are irrelevant, only the apache2handler SAPI is built.
Comment 14 Bug Zapper 2008-04-03 12:59:25 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 15 Bug Zapper 2008-05-06 20:22:48 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:

Note You need to log in before you can comment on or make changes to this bug.