Now =sys-apps/systemd-205 as said in http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/systemd/ChangeLog?view=markup "Drop USE=static-libs since it is no longer supported." and it breaks USE=static emerge =sys-fs/cryptsetup-1.6.1 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/cryptsetup/cryptsetup-1.6.1.ebuild?view=markup deps from cryptsetup-1.6.1.ebuild LIB_DEPEND="dev-libs/libgpg-error[static-libs(+)] dev-libs/popt[static-libs(+)] sys-apps/util-linux[static-libs(+)] gcrypt? ( dev-libs/libgcrypt[static-libs(+)] ) nettle? ( >=dev-libs/nettle-2.4[static-libs(+)] ) openssl? ( dev-libs/openssl[static-libs(+)] ) sys-fs/lvm2[static-libs(+)] sys-libs/e2fsprogs-libs[static-libs(+)] udev? ( virtual/udev[static-libs(+)] )"
Yes, both kmod and systemd (udev) upstreams decided to remove support for building static libraries libkmod.a and libudev.a The systemd ebuild is merely following what they made That indeed means sys-apps/systemd no longer supports USE="static" in sys-fs/lvm2 or sys-fs/cryptsetup But there is no bug, the dependencies are correctly handle, you should simply stop using USE="static" which is stupid flag to use to begin with Reassigning to systemd@ maintainers as a enhanchement request for getting libudev.a back, but not restoring it is fine too
configure: error: --enable-static is not supported by systemd And even if we work around that check, I doubt that it will work correctly since upstream doesn't use private namespaces properly.
Upstream is relying heavily on gcc symbol visibility [1]. One of the features of using this is that you don't have to use private name spaces the same way we did before. Their suggestion is that we should get binutils fixed so that static libraries also support visibility if we want to use static libraries. [1] http://gcc.gnu.org/wiki/Visibility
