Braden == Braden McDaniel [EMAIL PROTECTED] writes:
[...]
Braden Right... But aclocal pulls them from a standard location on the
Braden system. While this means the distribution may be colored by
Braden characteristics of the system where it's built, it does mean that in
Braden general
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Scott James Remnant wrote:
| That's actually an Autoconf macro that's failing, unfortunately. It's
| an irritant, but I've not figured out a way of getting around it short
| of overriding AC_MSG_ERROR.
Well, we already know the results of
On Thu, 2004-01-29 at 12:00, Peter O'Gorman wrote:
Scott James Remnant wrote:
| That's actually an Autoconf macro that's failing, unfortunately. It's
| an irritant, but I've not figured out a way of getting around it short
| of overriding AC_MSG_ERROR.
Well, we already know the results
On Thu, 2004-01-29 at 03:26, Alexandre Duret-Lutz wrote:
Anyway, the point is that you should not fear this. Installing
third-party macros in /usr/share/aclocal will continue to work.
Ah, good. Thank you for clarifying this.
--
Braden McDaniel e-mail: [EMAIL
On 2004-01-29T10:36-, Scott James Remnant wrote:
) On Thu, 2004-01-29 at 01:35, Daniel Reed wrote:
) The problem I was reporting is not so much the testing for C++ as it was the
) failing of ./configure if a C++ preprocessor was not available. There is C
) code in the various examples
On Thu, Jan 29, 2004 at 09:26:50AM +0100, Alexandre Duret-Lutz wrote:
..
Anyway, the point is that you should not fear this. Installing
third-party macros in /usr/share/aclocal will continue to work.
I think the problem arises when packages assume that libtool.m4 lives
in /usr/share/aclocal
Bob Friesenhahn wrote:
Autoconf now performs two levels of header tests. One level is to
check that the header file exists, while the other is to ensure that
it can be entirely preprocessed correctly. Probably /lib/cpp is used
because it is more work to figure out how to use the compiler as a
