[Dovecot] linking problems of dovecot 2.0.3
Hello,
I'm currently packaging dovecot 2.0.3 under Mandriva Linux. It has been using LDFLAGS="-Wl,--as-needed -Wl,--no-undefined" for shared libraries for over two years1. And I've found there are lots of linking problems with dovecot 2.0.3.
After some investigation, I've made small patch regarding dovecot 2.0.3, posted here: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/dovecot/branches/...
Even after applying mentioned patch, it still produce following errors:
make[3]: Entering directory /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common' /bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fstack-protector-all -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -export-dynamic -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -o libdovecot-login.la -rpath /usr/lib64/dovecot liblogin.la ../lib-dict/libdict.la ../lib-dovecot/libdovecot.la -lrt libtool: link: gcc -shared -Wl,--as-needed -Wl,--whole-archive ./.libs/liblogin.a ../lib-dict/.libs/libdict.a -Wl,--no-whole-archive -Wl,--as-needed -Wl,--no-undefined -Wl,-z -Wl,relro -Wl,-O1 -Wl,--build-id -Wl,-rpath -Wl,/tmp/dovecot/BUILD/dovecot-2.0.3/src/lib-dovecot/.libs -Wl,-rpath -Wl,/usr/lib64/dovecot -L/usr/lib64/ -lssl -lcrypto -ldl -lpthread ../lib-dovecot/.libs/libdovecot.so -lrt -Wl,-soname -Wl,libdovecot-login.so.0 -o .libs/libdovecot-login.so.0.0.0 ./.libs/liblogin.a(client-common.o): In function
get_var_expand_table':
/tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/client-common.c:372:
undefined reference to login_binary' ./.libs/liblogin.a(client-common.o): In function
client_create':
/tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/client-common.c:50:
undefined reference to client_vfuncs' ./.libs/liblogin.a(client-common-auth.o): In function
client_auth_parse_args':
/tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/client-common-auth.c:111:
undefined reference to login_binary' /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/client-common-auth.c:99: undefined reference to
login_binary'
./.libs/liblogin.a(client-common-auth.o): In function client_auth_begin': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/client-common-auth.c:491: undefined reference to
login_binary'
./.libs/liblogin.a(login-settings.o): In function login_settings_read': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/login-settings.c:195: undefined reference to
login_binary'
./.libs/liblogin.a(main.o): In function login_access_lookup_next': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/main.c:185: undefined reference to
login_binary'
./.libs/liblogin.a(main.o):/tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/main.c:338:
more undefined references to login_binary' follow ./.libs/liblogin.a(main.o): In function
main':
/tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/main.c:358:
undefined reference to login_process_preinit' ./.libs/liblogin.a(main.o): In function
main_init':
/tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/main.c:308:
undefined reference to clients_init' ./.libs/liblogin.a(main.o): In function
main_deinit':
/tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/main.c:317:
undefined reference to clients_deinit' ./.libs/liblogin.a(sasl-server.o): In function
anvil_check_too_many_connections':
/tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/sasl-server.c:187:
undefined reference to `login_binary'
collect2: ld returned 1 exit status
Could somebody take a look?
Thanks.
On Sun, 2010-09-19 at 14:04 +0800, Funda Wang wrote:
I'm currently packaging dovecot 2.0.3 under Mandriva Linux. It has been using LDFLAGS="-Wl,--as-needed -Wl,--no-undefined" for shared libraries for over two years[1]. And I've found there are lots of linking problems with dovecot 2.0.3.
After some investigation, I've made small patch regarding dovecot 2.0.3, posted here: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/dovecot/branches/...
I committed parts of it: http://hg.dovecot.org/dovecot-2.0/rev/26e88084bbc0
./.libs/liblogin.a(client-common.o): In function
get_var_expand_table': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/client-common.c:372: undefined reference to
login_binary'
The binary is expected to provide this symbol. This can't be fixed without a large API change. Maybe for v2.1.
Also besides these, linking plugins will fail with those LDFLAGS. I'm not sure about that .. seems wrong to have plugins also link to libraries that the parent binary is required to be linking to anyway..
On Mon, 2010-09-20 at 16:10 +0100, Timo Sirainen wrote:
Also besides these, linking plugins will fail with those LDFLAGS. I'm not sure about that .. seems wrong to have plugins also link to libraries that the parent binary is required to be linking to anyway..
Oh, and even by linking all of the libraries, I don't think that's enough for those plugins that use some functions directly from a binary (like imap-* plugins using imap functions from imap binary).
plugins are build with LDFLAGS="-Wl,--as-needed", with --no-defined stripped out. This is done automatically by Mandriva's patch to libtool.
But for shared libraries, if there are symbols defined in main program rather than library itself, that means libraries are only likely to work invoking the program, which is wrong. Because the library should be called by binary, rather the reverse.
2010/9/20 Timo Sirainen <tss@iki.fi>:
On Mon, 2010-09-20 at 16:10 +0100, Timo Sirainen wrote:
Also besides these, linking plugins will fail with those LDFLAGS. I'm not sure about that .. seems wrong to have plugins also link to libraries that the parent binary is required to be linking to anyway..
Oh, and even by linking all of the libraries, I don't think that's enough for those plugins that use some functions directly from a binary (like imap-* plugins using imap functions from imap binary).
On 21.9.2010, at 1.46, Funda Wang wrote:
But for shared libraries, if there are symbols defined in main program rather than library itself, that means libraries are only likely to work invoking the program,
Yes, that's how it was meant to be used.
which is wrong. Because the library should be called by binary, rather the reverse.
I agree it's ugly, but I don't know about wrong :) Even after fixing this, the end result is anyway pretty much the same: The only use case for dovecot-login.so is to build a login binary.
On Mon, 2010-09-20 at 16:10 +0100, Timo Sirainen wrote:
./.libs/liblogin.a(client-common.o): In function
get_var_expand_table': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/client-common.c:372: undefined reference to
login_binary'The binary is expected to provide this symbol. This can't be fixed without a large API change. Maybe for v2.1.
I fixed this now in v2.1: http://hg.dovecot.org/dovecot-2.1/rev/6f0396e35fd9
On Sat, 2011-04-30 at 13:20 +0300, Timo Sirainen wrote:
On Mon, 2010-09-20 at 16:10 +0100, Timo Sirainen wrote:
./.libs/liblogin.a(client-common.o): In function
get_var_expand_table': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/client-common.c:372: undefined reference to
login_binary'The binary is expected to provide this symbol. This can't be fixed without a large API change. Maybe for v2.1.
I fixed this now in v2.1: http://hg.dovecot.org/dovecot-2.1/rev/6f0396e35fd9
And I thought I might as well do this by default (unless I run into trouble with it): http://hg.dovecot.org/dovecot-2.1/rev/0be58f3930b2
participants (2)
-
Funda Wang
-
Timo Sirainen