I'm reverting this commit in sys-fs/udev's ebuild and opening this bug to avoid documenting this in the ebuild. The upstream commit I'm reverting is: http://cgit.freedesktop.org/systemd/systemd/commit/?id=5e63ce78b5018ba612e794a610a6f13c5eefade7 With a 1-liner like: sed -i -e '/--enable-static is not supported by systemd/s:as_fn_error:echo:' configure
+ 07 Jun 2013; Samuli Suominen <ssuominen@gentoo.org> udev-9999.ebuild: + Revert upstream commit that discontinued support for --enable-static in order + to get libudev.a back for USE="static" in sys-fs/cryptsetup and sys-fs/lvm2 + wrt #472608
Adding systemd since it will suffer the same problem.
Reverting this will cause link errors however, e.g. the following in systemd: http://lists.freedesktop.org/archives/systemd-devel/2013-June/011173.html
libkmod-util.o (symbol from plugin): In function `getline_wrapped': (.text+0x0): multiple definition of `memdup' util.o (symbol from plugin):(.text+0x0): first defined here libkmod-util.o (symbol from plugin): In function `getline_wrapped': (.text+0x0): multiple definition of `path_is_absolute' path-util.o (symbol from plugin):(.text+0x0): first defined here libkmod-util.o (symbol from plugin): In function `getline_wrapped': (.text+0x0): multiple definition of `path_make_absolute_cwd' path-util.o (symbol from plugin):(.text+0x0): first defined here collect2: error: ld returned 1 exit status make[2]: *** [test-udev] Error 1 Easy to fix with proper namespacing...
On a second look seems that whoever wrote this does not exactly consider private symbols something to care about so depmod uses stuff such as memdup. IF you have visibility on a dynamically linked depmod (and other tools) would fail to build at all. I guess some serious cleanup would be good if libkmod plans to be shared-only since not even its own tools would execute as it is now.
(In reply to William Hubbs from comment #3) > Reverting this will cause link errors however, e.g. the following in > systemd: > > http://lists.freedesktop.org/archives/systemd-devel/2013-June/011173.html unable to reproduce. got it building on first try and running fine :/
attach a complete build.log and emerge --info if you have such failure on Gentoo. thanks.
(In reply to Samuli Suominen from comment #6) > (In reply to William Hubbs from comment #3) > > Reverting this will cause link errors however, e.g. the following in > > systemd: > > > > http://lists.freedesktop.org/archives/systemd-devel/2013-June/011173.html > > unable to reproduce. got it building on first try and running fine :/ That is with system[static] and kmod[static] right?
Disregard my last comment. I meant udev[static-libs] and kmod[static-libs].
All, I found the following page on the gcc wiki talking about visibility [1]. This is what doesn't work in static libraries, so that is why they aren't supporting static linking. [1] http://gcc.gnu.org/wiki/Visibility
All, we need to look at why we are trying to support static linking and determine if we need to continue doing so instead of just reverting upstream changes.
(In reply to William Hubbs from comment #11) > All, > > we need to look at why we are trying to support static linking and > determine if we need to continue doing so instead of just reverting > upstream changes. oh, I see now that bug 409277 is already fixed. for me that means USE=static can be killed from cryptsetup and lvm2. USE="static udev" for sys-fs/lvm2 and sys-fs/cryptsetup needs libudev.a which then needs libkmod.a so indeed, upstream is right, static libudev.a and libkmod.a are useless and stupid workaround for sep. /usr idiocy however building static lvm2 and cryptsetup is explicitely supported by their upstreams by their configure scripts so there is in fact a conflict of intrest not only between what we want, but also between systemd(udev)/kmod vs. cryptsetup/lvm2 upstreams so how about getting the upstreams together...?
Ticket filed for cryptsetup upstream: http://code.google.com/p/cryptsetup/issues/detail?id=167
*** Bug 481772 has been marked as a duplicate of this bug. ***
*** Bug 510062 has been marked as a duplicate of this bug. ***
