dovecot - Jan 2007 - Build problems with non-standard location of mysql libs

Overall the build process for dovecot is very clean. I did however run 
into a significant problem when it came to locating the mysql libraries, 
especially when building a 64 bit executable but similar problems  
occured building a 32 bit executable. I am describing the 64 bit build 
issues below since that is the worst case scenario. Fixing the 64 bit 
build will automatically fix the 32 bit build.

In the Solaris world it is fairly common for software packages to be 
installed in the /opt tree rather than under /usr or /usr/local. In 
addition 64 bit libs are typically located under a path like /opt/lib/64 
or /opt/lib/sparcv9 and of course mysql libs are under /opt/lib/mysql or 
/opt/lib/sparcv9 | 64/mysql. The configure script for dovecot tries only 
a lib64 or /usr/lib64 path

I suggest that the conifgure script for dovecot offer a 
--with-mysql[=DIR] option so that it would be possible to provide the 
base location of the mysql installation as --with-mysql=/opt in the same 
manner that it is done for php.

I patched the configure script to search the /opt tree for mysql but 
unfortunately a side effect occured during the build which was compiled 
as 64 bit with the necessary CFLAGS and LDFLAGS input to the configure 
script.

Here is the configure. Note that the library search paths also include 
the Solaris specific sparcv9 paths so nothing special is required in the 
configure script to account for these platform specific paths. This is 
exactly the same method the we use to build php as a 64 bit app 
successfully. However, the configrue script needs to locate the 
/opt/include/mysql directory and also needs to find /opt/lib/mysql to at 
least trigger that it found the mysql installation. Even though 
/opt/lib/mysql is the path to the 32 bit library, the link tests will 
pass because the supplied LDFLAGS contain the path to the 64 bit library.

CFLAGS="-O3 -m64 -mcpu=ultrasparc -L/opt/lib/sparcv9 
-L/opt/lib/sparcv9/mysql -R/opt/lib/sparcv9 -R/opt/lib/sparcv9/mysql" \
CXXFLAGS="-O3 -m64 -mcpu=ultrasparc -L/opt/lib/sparcv9 
-L/opt/lib/sparcv9/mysql -R/opt/lib/sparcv9 -R/opt/lib/sparcv9/mysql" \
LDFLAGS="-O3 -m64 -mcpu=ultrasparc -L/opt/lib/sparcv9 
-L/opt/lib/sparcv9/mysql -R/opt/lib/sparcv9 -R/opt/lib/sparcv9/mysql" \
./configure --prefix=/opt \
--localstatedir=/var \
--enable-shared \
--disable-static \
--libdir=/opt/lib/sparcv9 \
--with-ssldir=/opt/ssl \
--with-ssl=openssl \
--with-storages=maildir,mbox \
--with-mysql


The next problem was that dovecot-auth failed to link:

/bin/bash ../../libtool --tag=CC   --mode=link gcc  -std=gnu99 -O3 -m64 
-mcpu=ultrasparc -L/opt/lib/sparcv9 -R/opt/lib/sparcv9 -Wall -W 
-Wmissing-prototypes -Wmissing-declarations -Wpointer-arith 
-Wchar-subscripts -Wformat=2 -Wbad-function-cast -I/opt/include    
-export-dynamic -O3 -m64 -mcpu=ultrasparc -L/opt/lib/sparcv9 
-R/opt/lib/sparcv9 -o dovecot-auth auth.o auth-cache.o 
auth-client-connection.o auth-master-connection.o auth-master-listener.o 
auth-module.o auth-request.o auth-request-handler.o auth-stream.o 
auth-worker-client.o auth-worker-server.o db-ldap.o db-sql.o 
db-passwd-file.o main.o mech.o mech-anonymous.o mech-plain.o 
mech-login.o mech-cram-md5.o mech-digest-md5.o mech-ntlm.o mech-gssapi.o 
mech-rpa.o mech-apop.o passdb.o passdb-blocking.o passdb-bsdauth.o 
passdb-cache.o passdb-ldap.o passdb-passwd.o passdb-passwd-file.o 
passdb-pam.o passdb-checkpassword.o passdb-shadow.o passdb-sia.o 
passdb-vpopmail.o passdb-sql.o userdb.o userdb-blocking.o userdb-ldap.o 
userdb-passwd.o userdb-passwd-file.o userdb-prefetch.o userdb-static.o 
userdb-vpopmail.o userdb-sql.o libpassword.a 
../lib-settings/libsettings.a ../lib-ntlm/libntlm.a ../lib-sql/libsql.a 
../lib/liblib.a -lpam  -L -L/opt/lib/mysql -L/opt/lib/sparcv9/mysql 
-lmysqlclient -lz -lm  -export-dynamic -ldl -lsocket -lnsl -lrt
mkdir .libs
gcc -std=gnu99 -O3 -m64 -mcpu=ultrasparc -Wall -W -Wmissing-prototypes 
-Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 
-Wbad-function-cast -I/opt/include -O3 -m64 -mcpu=ultrasparc -o 
dovecot-auth auth.o auth-cache.o auth-client-connection.o 
auth-master-connection.o auth-master-listener.o auth-module.o 
auth-request.o auth-request-handler.o auth-stream.o auth-worker-client.o 
auth-worker-server.o db-ldap.o db-sql.o db-passwd-file.o main.o mech.o 
mech-anonymous.o mech-plain.o mech-login.o mech-cram-md5.o 
mech-digest-md5.o mech-ntlm.o mech-gssapi.o mech-rpa.o mech-apop.o 
passdb.o passdb-blocking.o passdb-bsdauth.o passdb-cache.o passdb-ldap.o 
passdb-passwd.o passdb-passwd-file.o passdb-pam.o passdb-checkpassword.o 
passdb-shadow.o passdb-sia.o passdb-vpopmail.o passdb-sql.o userdb.o 
userdb-blocking.o userdb-ldap.o userdb-passwd.o userdb-passwd-file.o 
userdb-prefetch.o userdb-static.o userdb-vpopmail.o userdb-sql.o  
-L/opt/lib/sparcv9 libpassword.a ../lib-settings/libsettings.a 
../lib-ntlm/libntlm.a ../lib-sql/libsql.a ../lib/liblib.a -lpam 
-L/db/src/dovecot/dovecot-1.0.rc17_64bit/src/auth -L/opt/lib/mysql 
-L/opt/lib/sparcv9/mysql /opt/lib/mysql/libmysqlclient.so -L/opt/lib 
-lposix4 -lgen -lssl -lcrypto -lz -lm -ldl -lsocket -lnsl -lrt 
-R/opt/lib/mysql -R/opt/lib/mysql -R/opt/lib/sparcv9
ld: fatal: file /opt/lib/mysql/libmysqlclient.so: wrong ELF class: 
ELFCLASS32
ld: fatal: File processing errors. No output written to dovecot-auth

What is odd about the above is that the input to libtool is completely 
correct but the resulting gcc command converted -lmysqlclient to an 
absolute path of /opt/lib/mysql/libmysqlclient.so which is wrong for a 
64 bit build - hence the link failure. Why this happened is a mystery to 
me? If it had been left alone as -lmysqlclient the link would have been 
successful because the correct 64 bit library would have been found 
automatically.

To get around this problem I added  -lmysqlclient to the LDFLAGS input 
to the configure script which works but isn't very conventional.

It would be much cleaner if the --with-mysql had a [=DIR] option and the 
configure script used the same basic logic that is used in the php 
configure script for locating the mysql stuff. In addition it is 
essential that hard paths, especially to shared objects don't get 
generated during the build since that will block the automatic searching 
of libraries.

-- 
*Bob Atkins * 
/President/CEO/

*DigiLink, Inc. <http://www.digilink.net>*
Business Inter-net-working
*/The Cure for the Common ISP!/*

	

Phone: (310) 577-9450
Fax: (310) 577-3360
eMail: bob at digilink.net

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070111/961a8ccd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DigiLink_esig_logo.jpg
Type: image/jpeg
Size: 23605 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070111/961a8ccd/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bob.vcf
Type: text/x-vcard
Size: 266 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070111/961a8ccd/attachment-0002.vcf>

On Thu, 2007-01-11 at 12:54 -0800, Bob wrote:
> I suggest that the conifgure script for dovecot offer a
> --with-mysql[=DIR] option so that it would be possible to provide the
> base location of the mysql installation as --with-mysql=/opt in the
> same manner that it is done for php.
I'd rather not do that, since then people ask it for every single
library that Dovecot supports. It should be possible to do all this with
environment variables just as well. Also then you'll start seeing things
like:

./configure --with-mysql=/usr/local --with-postgres=/usr/local

Which causes multiple identical -I and -L options, unless I add more
code to remove the duplicates.

All in all, I think it just requires adding a lot more code to configure
without giving all that much benefits.
> CFLAGS="-O3 -m64 -mcpu=ultrasparc -L/opt/lib/sparcv9
> -L/opt/lib/sparcv9/mysql -R/opt/lib/sparcv9 -R/opt/lib/sparcv9/mysql"
> \
> CXXFLAGS="-O3 -m64 -mcpu=ultrasparc -L/opt/lib/sparcv9
> -L/opt/lib/sparcv9/mysql -R/opt/lib/sparcv9 -R/opt/lib/sparcv9/mysql"
> \
> LDFLAGS="-O3 -m64 -mcpu=ultrasparc -L/opt/lib/sparcv9
> -L/opt/lib/sparcv9/mysql -R/opt/lib/sparcv9 -R/opt/lib/sparcv9/mysql"
> \
I think you should rather do something like:

CPPFLAGS=-I/opt/mysql/include \
CFLAGS="-O3 -m64 -mcpu=ultrasparc" \
CXXFLAGS="-O3 -m64 -mcpu=ultrasparc" \
LDFLAGS="-L/opt/lib/sparcv9 -L/opt/lib/sparcv9/mysql -R/opt/lib/sparcv9
-R/opt/lib/sparcv9/mysql" \
./configure
> What is odd about the above is that the input to libtool is completely
> correct but the resulting gcc command converted -lmysqlclient to an
> absolute path of /opt/lib/mysql/libmysqlclient.so which is wrong for a
> 64 bit build - hence the link failure. Why this happened is a mystery
> to me? If it had been left alone as -lmysqlclient the link would have
> been successful because the correct 64 bit library would have been
> found automatically.
Maybe libtool found libmysqlclient.la, which contained path
to /opt/lib/mysql/libmysqlclient.so? Anyway, this is a libtool issue..

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070119/dcec5531/attachment.bin>