|Summary:||buildconf broken in two places|
|Product:||Apache httpd-2||Reporter:||Luke Scott <luke>|
|Component:||Build||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
Description Luke Scott 2010-10-18 21:52:48 UTC
There are two issues. #1) When I attempt to do ./buildconf I get: Copying libtool helper files ... $_prefix/share/aclocal/libtool.m4 not found I found this here: https://issues.apache.org/bugzilla/show_bug.cgi?id=48776 But I was unable to find a solution. Temporarily I edited /usr/bin/glibtoolize and changed: aclocaldir=$_prefix/share/aclocal to: aclocaldir=/usr/share/aclocal And that fixed this issue. I can confirm this on 2.2.14 through 2.2.16 (Didn't test 2.2.17 with this issue) #2) After working around #1 I get this: ./buildconf failed for apr-util (with a few possible relevant lines above this one) I was unable to find a work around. This ONLY applies to 2.2.15 through 2.2.17. It works fine with 2.2.14, which means this problem was introduced in 2.2.15. As far as I can tell each version builds fine as long as you dont need to run ./buildconf. But buildconf is needed, as far as I know, when you want to include optional extensions like mod_fcgid (these issues happen regardless if I have that included or not). Luke
Comment 1 Rainer Jung 2010-10-19 00:22:30 UTC
Can you try running after setting an environment variable named LIBTOOL_M4 to the full file name (including absolute directory path) of your libtool.m4 file? If there are still failures, e.g. your #2 failure, please provide full buildconf output.
Comment 2 Luke Scott 2010-10-19 15:33:02 UTC
For #1 here is the complete output: found apr source: srclib/apr found apr-util source: srclib/apr-util rebuilding srclib/apr/configure buildconf: checking installation... buildconf: python version 2.6.1 (ok) buildconf: autoconf version 2.61 (ok) buildconf: libtool version 2.2.4 (ok) Copying libtool helper files ... $_prefix/share/aclocal/libtool.m4 not found ./buildconf failed for apr I tried setting LIBTOOL_M4 to /usr/share/aclocal and /usr/share/aclocal/libtool.m4 and nothing changed (output is still the same as above). This is the code in /usr/bin/glibtoolize which is bundled with OS X 10.6.4: prefix=/usr datadir=$_prefix/share pkgdatadir=$_prefix/share/libtool pkgltdldir=$_prefix/share/libtool aclocaldir=$_prefix/share/aclocal Not sure how ./buildconf gets the value of libtool.m4, but if it's reading it directly "$_prefix" is not being parsed. For #2 (still manually editing glibtoolize to aclocaldir=/usr/share/aclocal): The output is: found apr source: srclib/apr found apr-util source: srclib/apr-util rebuilding srclib/apr/configure buildconf: checking installation... buildconf: python version 2.6.1 (ok) buildconf: autoconf version 2.61 (ok) buildconf: libtool version 2.2.4 (ok) Copying libtool helper files ... buildconf: Using libtool.m4 at /usr/share/aclocal/libtool.m4. Creating include/arch/unix/apr_private.h.in ... Creating configure ... Generating 'make' outputs ... rebuilding rpm spec file rebuilding srclib/apr-util/configure Looking for apr source in /Users/lukescott/Downloads/httpd-2.2.17/srclib/apr cp: /Users/lukescott/Downloads/httpd-2.2.17/srclib/apr/build/config.guess: No such file or directory cp: /Users/lukescott/Downloads/httpd-2.2.17/srclib/apr/build/config.sub: No such file or directory ./buildconf failed for apr-util Again this isn't an issue in version 2.2.14. The above was just tested in build 2.2.17
Comment 3 William A. Rowe Jr. 2018-11-07 21:08:46 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.