Summary: | dev-libs/apr-util-0.9.12-r1 multilib strict failure (ignores ./configure --libdir parameter) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexis Ballier <aballier> |
Component: | Current packages | Assignee: | Apache Team - Bugzilla Reports <apache-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | amd64, cilly, gregg.casillo |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Alexis Ballier
![]() (In reply to comment #0) > when autoconf 2.61 is used to regenerate ./configure script, it ignores the > --libdir parameter, whatever you give him it sets it to $exec_prefix/lib what > causes multilib scrict failures. > > > > its configure.in contains : AC_PREREQ(2.13) > > what fixed it for me was to force using autoconf 2.1 (& automake 1.8 for > aclocal, newer versions will cause an aclocal error about autom4te). > > snippet : > > WANT_AUTOMAKE=1.8 > WANT_AUTOCONF=2.1 Fixed now, hopefully won't break again :S Now I am getting the error * Failed Running aclocal ! This is on a fresh install I am building using ~amd64. The relevant line of the .out file seems to be ac-wrapper: Autoconf 2.13 doesn't contain autom4te. Either unset WANT_AUTOCONF or don't execute anything that would use autom4te. aclocal-1.8: autom4te failed with exit status: 1 Removing the WANT_* allows it to build but as Alexis points out I get multilib-strict failures. Can anyone else reproduce the failure I am seeing or is it some problem with my new install possibly? Should have thought of this before posting, setting WANT_AUTOMAKE=1.7 fixes it for me and I don't get the multilib-strict failure. Can anyone else confirm this? This is on a fresh ~amd64 (started updating/compiling yesterday). *** Bug 169975 has been marked as a duplicate of this bug. *** (In reply to comment #3) > Should have thought of this before posting, setting WANT_AUTOMAKE=1.7 fixes it > for me and I don't get the multilib-strict failure. Can anyone else confirm > this? This is on a fresh ~amd64 (started updating/compiling yesterday). Fixed now, finally. *** Bug 169983 has been marked as a duplicate of this bug. *** |