[Dovecot] rc15 'configure' fails at "unexpected token `SSL,'"
snowcrash+dovecot
schneecrash+dovecot at gmail.com
Wed Dec 6 15:35:33 UTC 2006
hi,
in summary,
(1) 'unexpected token SSL' issue resolved with *update* of
pkg-config, libiconv & gettext
(2) error "required file `./config.rpath' not found" with latest
gettext/automake versions; requires dummy config.rpath
On 12/6/06, Marcus Rueckert <rueckert at informatik.uni-rostock.de> wrote:
> did you run autoreconf or something?
> those error messages sound like that. they should not happen when you
> used the configure from the tarball.
kind of. i'd normally run,
autoreconf -i -f
but, it's (currently) having an issue with not respecting my AUTOMAKE
env var (for add'n of automake cmd line params), so, instead, i run
the "itemized" equivalent of cvs co's 'autogen.sh'. i.e.,
aclocal
autoheader
glibtoolize --force --copy
automake --add-missing --copy
autoconf
On 12/6/06, Chris Wakelin <c.d.wakelin at reading.ac.uk> wrote:
> You're missing pkgconfig, I think. See
> http://pkgconfig.freedesktop.org/wiki/
nope. i have pkg-config v0.21 built from src & operational (and often
used ...),
which pkg-config
/usr/local/bin/pkg-config
pkg-config --debug --version
Option --debug seen
Option --version seen
Error printing enabled by default due to use of --version, --libs,
--cflags, --libs-only-l, --libs-only-L, --libs-only-other,
--cflags-only-I, --cflags-only-other or --list. Value of
--silence-errors: 0
Error printing enabled
0.21
pkg-config --libs openssl
-Wl,-search_paths_first -L/usr/local/ssl/lib -L/usr/local/lib
-lssl -lcrypto -lz
On 12/6/06, Marcus Rueckert <rueckert at informatik.uni-rostock.de> wrote:
> and the m4 files for AM_ICONV. maybe more.
hmm. this got me thinking.
i'd recently upgraded to,
autoconf --version
autoconf (GNU Autoconf) 2.61
just in case, i rebuilt-from-src,
pkg-config v0.21
libiconv v1.11
gettext v0.16
with latest autoconf, etc.
and, this issue goes away!
hmmm. something in the .m4's changed format/syntax perhaps?
a bit troubling not to know for sure, but,
'future note to self': clean-up/update toolchain after any/all
auto-foo version updates.
anyway, now, with tarball, i get a complaint,
automake --add-missing --copy
configure.in:15: required file `./config.rpath' not found
but, noting in ChangeLog,
NOTE: from ChangeLog ...
2004-10-25 18:50 Timo Sirainen <tss at iki.fi>
* Makefile.am: config.rpath isn't supposed to be here..
this seems relevant.
checking in cvs co of 10-branch, i get the same,
configure.in:15: required file `./config.rpath' not found
googl'ing, i find,
"gettext-related test failures: config.rpath presence"
http://www.mail-archive.com/automake-patches@gnu.org/msg00426.html
which suggests,
AM_PROG_GETTEXT of gettext >= 0.14.3
requires `config.rpath' to be present, and automake now enforces
this.
again, i'm using latest versions of,
gettext v0.16
libiconv v1.11
automake (GNU automake) 1.10
which looks likely to be causing the/a problem
so, providing a "dummy" with,
touch config.rpath
now,
automake --add-missing --copy
is 'happy' for both tarball AND cvs co.
subsequent
./configure ...
make
make check
of both/either
cvs 10-branch head
1.0.rc15 tarball
are now ok.
> so it might be interesting to find out why he rerun autotools
well, with cvs co, you must.
and, with tarballs, i've found it wise to get libtool & auto-foo files
all in-sync/consistent. especially when using upgraded components
that likely are different than those used in the target app's typical
dev env.
also, it's a frequent -- not always conclusive -- indicator that
something's amiss if it does NOT behave.
thanks.
More information about the dovecot
mailing list