Which has obvious reasons for NOT being a good idea (see http://blog.flameeyes.eu/2008/12/24/library-on-a-collision-course-on-the-screen on a similar issue). HTH, Diego
Security bug 252567 is of no concern here (as opposed to PHP), because this is only a client-side DoS. A fix is preferable nevertheless, since an attacker could cause the application to crash via a crafted email.
I have no idea why this command creates a library dynamically linking every dependency, but only statically linking c-client: g++ -fPIC -g -O2 -Wall -Woverloaded-virtual -fno-operator-names -D_GNU_SOURCE -DHAVE_VDR=1 -shared AxVdrTools.o AxPluginSetup.o AxPluginMailBox.o AxMailWrapper.o AxMenuMailViewBase.o AxMenuMailBoxView.o AxMenuMailListView.o AxMenuMailView.o AxMenuConfigPlugin.o AxMenuConfigCommon.o AxMenuConfigMailBox.o AxMailChecker.o AxMenuFolders.o AxMenuLogView.o i18n.o ./AxLib/src/Tools/String.o ./AxLib/src/Tools/InstanceCounter.o ./AxLib/src/Mail/CallBackDispatcher.o ./AxLib/src/Mail/CallBackProcessor.o ./AxLib/src/Mail/Internal.o ./AxLib/src/Mail/LogHandlerCBP.o ./AxLib/src/Mail/LogHandler.o ./AxLib/src/Mail/MailBoxCBP.o ./AxLib/src/Mail/MailBox.o ./AxLib/src/Mail/MailBoxInternal.o ./AxLib/src/Mail/MailBoxMgr.o ./AxLib/src/Mail/MailBoxSetup.o ./AxLib/src/Mail/Mail.o ./AxLib/src/Mail/MailFolder.o ./AxLib/src/Mail/MailPart.o ./AxLib/src/Mail/MsgBody.o ./AxLib/src/Mail/MsgCache.o ./AxLib/src/Mail/Request.o ./AxLib/src/Mail/Tools.o ./AxLib/src/VDR/Action.o ./AxLib/src/VDR/MenuCode.o ./AxLib/src/VDR/MenuText.o ./AxLib/src/VDR/Thread.o ./AxLib/src/VDR/Tools.o -lc-client -lssl -lpam -o libvdr-mailbox.so
# lddtree.sh /usr/lib/vdr/plugins/libvdr-mailbox.so.1.7.4 libvdr-mailbox.so.1.7.4 => /usr/lib/vdr/plugins/libvdr-mailbox.so.1.7.4 (interpreter => none) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 libdl.so.2 => /lib/libdl.so.2 ld-linux.so.2 => /lib/ld-linux.so.2 libpam.so.0 => /lib/libpam.so.0 libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.3.3/libstdc++.so.6 libm.so.6 => /lib/libm.so.6 libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.3.3/libgcc_s.so.1 libc.so.6 => /lib/libc.so.6
It seems net-libs/c-client is missing the file libc-client.so, so -lc-client automatically falls back to using the static version: # equery files c-client|grep lib /usr/lib /usr/lib/c-client.a /usr/lib/libc-client.a /usr/lib/libc-client.so.1.0.0 ldconfig only creates /usr/lib/libc-client.so.1, but no link without suffix after the .so # ls -1 /usr/lib/*c-client* /usr/lib/c-client.a /usr/lib/libc-client.a /usr/lib/libc-client.so.1 /usr/lib/libc-client.so.1.0.0 Adding this by hand makes c-client nice and linkable as shared lib.
the ebuild incorrectly claims: # these are created by ldconfig! #cd ${D}/usr/$(get_libdir) #ln -s libc-client.so.1.0.0 libc-client.so.1 #ln -s libc-client.so.1.0.0 libc-client.so ldconfig will create the SONAME (.so.1), but it will not create the linkable one (.so). the ebuild really should do both instead of relying on ldconfig anyways.
*** Bug 255120 has been marked as a duplicate of this bug. ***
+*c-client-2007e-r2 (11 May 2011) + + 11 May 2011; Eray Aslan <eras@gentoo.org> +c-client-2007e-r2.ebuild: + Symlink shared library - bug #255118. Drop kolab USE flag. +
