Subject: Re: [Newbie] some c-ares clarifications sought

Re: [Newbie] some c-ares clarifications sought

From: <izimmerman_at_borderware.com>
Date: 2006-01-09

Ian> CVS; oh well, I guess I have to do that anyway to contribute the
Ian> DNS packet code, but I'll have to convince the superiors it's safe.
Ian> Or should I wait for the next release?

Daniel> That's your pick. I plan to make a release "soon", but I'm not
Daniel> sure exactly when that is. There's no real rush to release as I
Daniel> see it.

I got the curl CVS tree, but unfortunately I am caught in the autotools
snare :-( Having to install multiple versions of each auto*, one for
each project, is bad enough; but I am also on FreeBSD, meaning my m4
is not GNU m4, and I am afraid to replace it.

<rant>
This is why I decided lately to avoid _any_ of the auto* (even autoconf,
which is the most useful of them) and program to strict SUSv3/POSIX.
I mean, how long are we going to support broken legacy platforms,
anyway?
</rant>

A secondary problem is that buildconf inside the ares subtree fails like this:
izimmerman@ianbuild:~/work/bsn/scs/contrib/curl/ares$ ./buildconf
configure.ac:23: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:41: error: possibly undefined macro: AC_DISABLE_SHARED
configure.ac:60: error: possibly undefined macro: AC_PROG_LIBTOOL
Makefile.am:3: Libtool library used but `LIBTOOL' is undefined
Makefile.am:3:
Makefile.am:3: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
Makefile.am:3: to `configure.ac' and run `aclocal' and `autoconf' again.

This might be because of the different m4, or because nobody ever tried
to build the subtree separately.

Ian
Received on Mon Jan 9 22:03:53 2006