eternaltyro / cryptsetup

Since Google code is shuttering...
http://code.google.com/p/cryptsetup
GNU General Public License v2.0
0 stars 0 forks source link

--enable-static-cryptsetup is no longer valid with latest udev #167

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
It's no longer possible to compile libkmod.a because configure.ac of kmod 
explicitely disallows it since the released version 14:

http://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/?id=b7016153ec87dba
2b0f0d182cc8f1e3b12f4dfaf

Then it's no longer possible to compile libudev.a because configure.ac of udev 
explicitely disallows it since the released version 205:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=5e63ce78b5018ba612e794a61
0a6f13c5eefade7

As discussed between systemd/udev and kmod maintainers at the systemd mailing 
list:

http://lists.freedesktop.org/archives/systemd-devel/2013-June/011173.html

The reason I'm filing this bug is that I'd like to very much see how this will 
be solved in the end of cryptsetup and LVM2.
As in, I'd like to see this solved (decided) between LVM2 (which has the same 
problem now), cryptsetup vs. systemd (udev) and kmod maintainers.
For now I've reverted those disallowing static commits from distribution 
packaged udev and kmod to retain the current status (Gentoo, but this will 
affect any others wanting to build eg. Debian styled -dev packages or whatever)

Will you follow suit and ditch support of building static-cryptsetup entirely? 
Force the compile without udev when --enable-static-cryptsetup is enabled and 
print a warning? Document that building static-cryptsetup needs hacked kmod, 
systemd (udev)?

Original issue reported on code.google.com by ssuomine...@gmail.com on 5 Jul 2013 at 1:15

GoogleCodeExporter commented 9 years ago
Some minor discussion in downstream bug report, 
http://bugs.gentoo.org/show_bug.cgi?id=472608 but nothing that adds more 
information really.

Original comment by ssuomine...@gmail.com on 5 Jul 2013 at 1:17

GoogleCodeExporter commented 9 years ago
cryptsetup does not need udev internally at all, it is libdevmapper backend 
library dependency.
Unfortunately without libdevmapper cryptsetup is completely unusable.
(IOW once libdevmapper can be compiled statically cryptsetup can be built 
again.)

But I would like to have static build still supported (the world is more than 
Fedora which disallows static linking.) BTW I am using static builds myself for 
testing (I can have all versions and no dependency on system libraries - very 
useful for local quick regression tests.)

But really, it is systemd issue, udev is part of systemd now. I think your 
distro solution is the best you can do now.

Original comment by gmazyl...@gmail.com on 5 Jul 2013 at 1:46

GoogleCodeExporter commented 9 years ago
So I tried this directly on Gentoo with udev static workaround (for bug 472608) 
removed.

Indeed, lvm2 (devicemapper lib) fails to build. In this configuration you have 
to compile lvm2 (resp. device-mapper) with udev disabled (no static udev 
library, it cannot link it -> must add"-udev" USE flag).

Cryptsetup does not need udev at all, it just takes library requirement from 
lvm2 for devicemapper lib, as you can check with pkgconfig:

# pkg-config --libs devmapper --static
-L/lib -ldevmapper -ludev -lrt 

(If you compile lvm2 with udev disabled, -ludev disappears and cryptsetup is 
not linked to it as well.)

IOW there is no bug in cryptsetup - is still can support static build, you just 
need to have environment supporting it. Once you are using systemd > 205, 
devicemapper must be compiled without udev (this unfortunately means some old 
bugs reapear but that's out of cryptsetup scope :-)

If lvm developers decide to not support static libdevamapper build at all 
cryptsetup will follow and static build will be disabled (or I will solve it 
differently).

But for now, it works exactly as expected.

I would suggest Gentoo developers to add some warning and compile lvm2 with 
-udev if static build required. You should see the same problem for 
multipath-tools (e.g. kpartx) and dmraid static builds. (Or if existing 
workaround in ebuild script is ok, then this is the best solution.)

Please let me know if there is still any problem - I am using Gentoo for low 
level testing so static build is sometimes very useful for me as well.

Original comment by gmazyl...@gmail.com on 27 Jul 2013 at 10:10