[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