hi timo,

patch applied to 1.1.beta9 source

now,

configure make make check

are OK, now, on *both* Tiger/Leopard.

just to be clear -- minor mixup in your comment above ...

it's _not_ broken on Leopard, it was "broken" on Tiger

works for now!

Why is it linking any of -lreadline -lncurses -lpthread anyway? What line do they exist in Makefile? Does config.log say something about them?

nothing in ...

egrep "readline|ncurses|pthread" {Makefile,config.log}
	(empty)

coming along from sqlite3, i believe ...

otool -L /usr/local/sqlite/lib/libsqlite3.dylib
	/usr/local/sqlite/lib/libsqlite3.0.dylib (compatibility version

9.0.0, current version 9.6.0) /usr/local/lib/libreadline.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /usr/local/lib/libncurses.5.6.dylib (compatibility version 5.6.0, current version 5.6.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

where

ls -al /usr/local/dovecot/libexec/dovecot/deliver
	-rwxr-xr-x 1 root wheel 926480 Nov 27 23:52

/usr/local/DarkMatter/dovecot/libexec/dovecot/deliver

otool -L /usr/local/dovecot/libexec/dovecot/deliver
	/usr/local/DarkMatter/sqlite/lib/libsqlite3.0.dylib (compatibility

version 9.0.0, current version 9.6.0) /usr/local/lib/libreadline.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /usr/local/lib/libncurses.5.6.dylib (compatibility version 5.6.0, current version 5.6.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) /usr/local/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

hth!

hi timo,

...

it's _not_ broken on Leopard, it was "broken" on Tiger

Oh, interesting. I guess I won't add this workaround to Dovecot sources then. People have been building Dovecot on OSX for a long time and no-one's complained about this before.

so have i ...

but, i'd gather they've _not_ been using 1.1.b9 & 'new' gcc 4.2.1 ... especially on Tiger. v421 is a different beast, with more rigorous checking, and some different option support ... i'd bet it's related. but not sure atm :-|

...

...

Why is it linking any of -lreadline -lncurses -lpthread anyway? What line do they exist in Makefile? Does config.log say something about them? .. coming along from sqlite3, i believe ...

So, the next question: Why is sqlite3 linked to anything else than dovecot-auth? :)

probably a pickup from LDFLAGS, as i config/build as:

patch -p1 < /usr/ports/dovecot/patch-hash-dovecot.txt

# find libmysqlclient_r perl -pi -e 's/AC_CHECK_LIB\(mysqlclient,/AC_CHECK_LIB\(mysqlclient_r,/g' configure.in perl -pi -e 's/mysql_lib=\"\-lmysqlclient \-lz \-lm"/mysql_lib=\"\-lmysqlclient_r \-lz \-lm\"/g' configure.in

setenv LDFLAGS "-L/usr/local/db46/lib -L/usr/local/sqlite/lib -lsqlite3 -L/usr/local/mysql/lib/mysql -L/usr/local/lib -liconv"

setenv CPPFLAGS "-I/usr/local/db46/include -I/usr/local/sqlite/include -I/usr/local/mysql/include/mysql -I/usr/local/include"

./configure
--config-cache
--prefix=/usr/local/dovecot
--with-moduledir=/usr/local/dovecot-plugins
--with-libiconv-prefix=/usr/local
--with-ssl=openssl
--with-ssldir=/var/CERTS
--enable-maintainer-mode
--disable-debug
--enable-ipv6
--disable-static --enable-shared
--with-ioloop=best
--with-db
--with-mysql
--with-sqlite
--with-sql-drivers=mysql,sqlite
--with-deliver
--with-pop3d
--with-storages=maildir,mbox,dbox,cydir,raw

iirc, the "--with-sqlite" config option does not take a DIR arg. so to tell it where, LDFLAGS are req'd.

i might suggest DIR options for spec'n of non-standard install loc'ns for each opt. no?

hth.

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.

I think as a user it's a lot easier to use and understand if you're just instructed to say:

CPPFLAGS=-I/usr/local/include LDFLAGS=-I/usr/local/lib ./configure

instead of:

./configure --with-mysql=/usr/local --with-sqlite=/usr/local --with-pgsql=/usr/local --with-ten-other-packages=/usr/local

again, i don't agree. LDFLAGS, CPPFLAGS, etc are _global_ var instances ... used by autofoo across the entier install. often end up with stuff linked-in where you don't necessarily need/want it.

also, lots of other apps seem to provide the option. i suppose they do it for a reason ...

but it's simply personal preference -- and, like i said, ultimately your call! :-)

Binary packages sometimes install things to different locations than a standard installation. Like the header might not be in /usr/include/, but in /usr/include/package/. For that case this doesn't really work.

well, first, i don't *use* binary packages ... i build from source.

but, anyway, it works just fine -- if you define/ues the vars properly. i do it all the time with other apps.

And lots of bloat to both configure code and ./configure --help..

some say bloat, some say flexibility. again, just opinion. if lean-as-possible is the goal, then you're absolutely right.

if, however, you want to allow folks to built dovecot on *their* system layout -- not just distros' -- then some flexibility needs to be there.

-I and -L don't really matter if they're in global CPPFLAGS/LDFLAGS.

hm? items def'd in LDFLAGS don't matter? then why your question about why -lsqlite is linked in? it's _only_ coming from LDFLAGS ... apparently not as you expected, no?

anyway, i can simply workaround lack of flexibility if/as needed. no changes to 'required'.

cheers.

That's why libraries shouldn't be added to them, only linker flags.

agreed. which i would have done if SQL_LIBS had been mentioned in "./configure --help" output. adding to LIBS had not worked ...

it was not. now that _you've_ mentioned it, i'll try it and see.

(agh! bounced ...)

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.