[Dovecot] 1.1beta9 'make' fails on osx/Tiger, but OK on osx/Leopard (multiple definitions of symbol _hash_create)

snowcrash schneecrash at gmail.com
Wed Nov 28 17:04:57 EET 2007


> Doesn't it have -lmysqlclient at all?

on this box, yes, it does:

	ls /usr/local/mysql/lib/mysql/libmysqlclient*
		/usr/local/mysql/lib/mysql/libmysqlclient.15.0.0.dylib
		/usr/local/mysql/lib/mysql/libmysqlclient.15.dylib
		/usr/local/mysql/lib/mysql/libmysqlclient.a
		/usr/local/mysql/lib/mysql/libmysqlclient.dylib
		/usr/local/mysql/lib/mysql/libmysqlclient.la
		/usr/local/mysql/lib/mysql/libmysqlclient_r.15.0.0.dylib
		/usr/local/mysql/lib/mysql/libmysqlclient_r.15.dylib
		/usr/local/mysql/lib/mysql/libmysqlclient_r.a
		/usr/local/mysql/lib/mysql/libmysqlclient_r.dylib
		/usr/local/mysql/lib/mysql/libmysqlclient_r.la

> Should I just add another
> -lmysqlclient_r check and use it if -lmysqlclient isn't found?

you can add a conditional ... but, imho, you need the option to
_specify_ using the threaded libs,not just fallback to them.


> > setenv LDFLAGS "-L/usr/local/db46/lib -L/usr/local/sqlite/lib
> > -lsqlite3 -L/usr/local/mysql/lib/mysql -L/usr/local/lib -liconv"
> ..
> > iirc, the "--with-sqlite" config option does not take a DIR arg.  so
> > to tell it where, LDFLAGS are req'd.
>
> The -L parameters are good enough in there, but isn't -lsqlite3 added
> automatically? If not, put it to SQL_LIBS instead if LDFLAGS.

aha -- SQL_LIBS.

you might wish to add mention of that to:

	./configure --help | grep -i SQL
	  --with-sql=yes|plugin   Build with generic SQL support
	  --with-pgsql            Build with PostgreSQL driver support
	  --with-mysql            Build with MySQL driver support
	  --with-sqlite           Build with SQLite3 driver support
	  --with-sql-drivers      Build with specified SQL drivers (all)

> > i might suggest DIR options for spec'n of non-standard install loc'ns
> > for each opt. no?
>
> I just wrote about this privately to another guy, here's some
> copy&pasting:
>
> Also I think those --with-package=/path parameters' functionality could
> be misundertood easily. They don't really specify that the given package
> is used from /path. They just modify the generic CPPFLAGS/LDFLAGS
> environment and let the compiler/linker find the packages wherever they
> happen to be first in the path.
>
> Also I could never figure out when compiling other systems what I should
> use as the package path. Does the configure script use the given path as
> base path for <path>/include and <path>/lib, or does it assume that both
> the include and lib files are there or something else? What if I have
> the include and lib files in completely different locations?
>
> I've never liked those parameters either as a user or as a developer, so
> I doubt I'll ever add them to Dovecot.

that's, of course, your call ... but, honestly, all of it's easily --
and frequently -- dealt with.  you simply say what you mean.  when
clearly stated, there's no room for misunderstanding; and that
explanation is completely in your hands.

e.g., either just provide

  --with-mysql=DIR   DIR is the install prefix

or 'all three'

  --with-mysql=DIR            DIR is the install prefix
  --with-mysql-libs=DIR       overrides the DIR where libmysqlclient(_r).* is
  --with-mysql-includes=DIR   overrides the DIR where mysql.h is

or some such.

> They just modify the generic CPPFLAGS/LDFLAGS

only if you defined it that way.  one can readily defined
--with-mysql=$var, then assign DOVECOT_MYSQL_LIBS=$/var/mysql/libs
(e.g), and use it specifically, rather than the generic/global LDFLAGS

personally, i find it a lot LESS confusing than having to dig for /
guess if an env var SQLITE3_LIBS exists ...

just my $0.02!

cheers.


More information about the dovecot mailing list