Created attachment 383310 [details] build log Linking sys-fs/lvm2-2.02.109[static] against sys-apps/util-linux-2.25[static-libs] and sys-fs/udev-216[static-libs], I get a message, which presumably is the cause of the build failure since I see no explicit error message and the warnings (which are also mentioned in bug 491746) should not cause the build to fail. /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libblkid.a(libcommon_la-fileutils.o): In function `mkdir_p': /var/tmp/portage/sys-apps/util-linux-2.25/work/util-linux-2.25/lib/fileutils.c:94: multiple definition of `mkdir_p' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libudev.a(libsystemd_shared_la-mkdir.o):/var/tmp/portage/sys-fs/udev-216/work/systemd-216/src/shared/mkdir.c:145: first defined here
Created attachment 383312 [details] emerge --info
This is not specific to the version of lvm2: even the 2.02.107 I currently have installed will fail to re-emerge, with the same message. Not surprising, since this is likely due to changes in util-linux, udev or gcc.
Judging from the dynamic libraries, it seems as if neither util-linux nor udev explicitely exports the mkdir_p function. So the symbol is probably for internal use by its respective libraries only. Which means that one could rename the symbol to avoid the conflict, without affecting the public API of either package. This could probably be done with a preprocessor macro included in CFLAGS. Like -Dmkdir_p=util_linux_mkdir_p resp. -Dmkdir_p=udev_mkdir_p.
With the following settings, all three packages emerged successfully: ==> /etc/portage/env/sys-apps/util-linux <== CFLAGS="${CFLAGS} -Dmkdir_p=util_linux_mkdir_p" CXXFLAGS="${CXXFLAGS} -Dmkdir_p=util_linux_mkdir_p" ==> /etc/portage/env/sys-fs/udev <== CFLAGS="${CFLAGS} -Dmkdir_p=udev_mkdir_p" CXXFLAGS="${CXXFLAGS} -Dmkdir_p=udev_mkdir_p"
after manually unmasking the static use flag it compiles fine here without the /etc/portage/env/ mods
seems the bug is realted the systemd - i don't use systemd, maybe it should just be masked for people that use systemd
(In reply to puchu from comment #6) > seems the bug is realted the systemd - i don't use systemd, maybe it should > just be masked for people that use systemd I'm not using systemd either. The udev source tree contains a directory of that name, because it is a common codebase. Perhaps eudev does not. (In reply to puchu from comment #6) > seems the bug is realted the systemd - i don't use systemd, maybe it should > just be masked for people that use systemd I can't remember any mask related to static, but I'm on ~amd64. It would be interesting to see the output of these commands on your system: objdump -t /usr/lib64/libblkid.a | grep mkdir objdump -t /usr/lib64/libudev.a | grep mkdir
objdump -t /usr/lib64/libblkid.a | grep mkdir 0000000000000000 *UND* 0000000000000000 mkdir objdump -t /usr/lib64/libudev.a | grep mkdir 0000000000000000 *UND* 0000000000000000 mkdirat 0000000000000000 *UND* 0000000000000000 mkdir_parents 0000000000000000 *UND* 0000000000000000 mkdir 0000000000000000 *UND* 0000000000000000 mkdirat libsystemd_shared_la-mkdir.o: file format elf64-x86-64 0000000000000000 l d .text.mkdir_safe_internal 0000000000000000 .text.mkdir_safe_internal 0000000000000000 l d .text.mkdir_safe 0000000000000000 .text.mkdir_safe 0000000000000000 l d .text.mkdir_parents_internal 0000000000000000 .text.mkdir_parents_internal 0000000000000000 l d .text.mkdir_parents 0000000000000000 .text.mkdir_parents 0000000000000000 l d .text.mkdir_p_internal 0000000000000000 .text.mkdir_p_internal 0000000000000000 l d .text.mkdir_p 0000000000000000 .text.mkdir_p 0000000000000000 l d .text.mkdir_p_prefix 0000000000000000 .text.mkdir_p_prefix 0000000000000000 g F .text.mkdir_safe_internal 000000000000010b .hidden mkdir_safe_internal 0000000000000000 g F .text.mkdir_safe 000000000000000c .hidden mkdir_safe 0000000000000000 *UND* 0000000000000000 mkdir 0000000000000000 g F .text.mkdir_parents_internal 0000000000000223 .hidden mkdir_parents_internal 0000000000000000 g F .text.mkdir_parents 0000000000000013 .hidden mkdir_parents 0000000000000000 g F .text.mkdir_p_internal 000000000000008f .hidden mkdir_p_internal 0000000000000000 g F .text.mkdir_p 0000000000000013 .hidden mkdir_p 0000000000000000 g F .text.mkdir_p_prefix 000000000000000c .hidden mkdir_p_prefix 0000000000000000 *UND* 0000000000000000 mkdir_parents
(In reply to puchu from comment #8) > objdump -t /usr/lib64/libblkid.a | grep mkdir > 0000000000000000 *UND* 0000000000000000 mkdir So your sys-apps/util-linux doesn't provide the symbol in question. Could it be you are using a version prior to 2.25? The way I see it, the symbol was moved from libmount.la (which is only included in libmount.a) to libcommon.la (which is included in libblkid.a as well) in a commit first included in v2.25-rc2. https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=934530c7e831e6265142df14e08246dcb4952872
(In reply to Martin von Gagern from comment #9) > (In reply to puchu from comment #8) > > objdump -t /usr/lib64/libblkid.a | grep mkdir > > 0000000000000000 *UND* 0000000000000000 mkdir > > So your sys-apps/util-linux doesn't provide the symbol in question. Could it > be you are using a version prior to 2.25? The way I see it, the symbol was > moved from libmount.la (which is only included in libmount.a) to > libcommon.la (which is included in libblkid.a as well) in a commit first > included in v2.25-rc2. > https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/ > ?id=934530c7e831e6265142df14e08246dcb4952872 im runnning sys-apps/util-linux-2.24.1-r3
Note that systemd (udev) upstream doesn't support static linking, it's configure.ac has... AS_IF([test "x$enable_static" = "xyes"], [AC_MSG_ERROR([--enable-static is not supported by systemd])]) ...to prevent building of libudev.a, required by USE="static udev" So I'm not suprised by this bug. Perhaps we should add... REQUIRED_USE="static? ( !udev )" ...like sys-fs/cryptsetup got already REQUIRED_USE="static? ( !gcrypt )" wrt bug 496612, comment #23
> Perhaps we should add... > > REQUIRED_USE="static? ( !udev )" I'm not comfortable with this. In the day-to-day operations of my system, I am using udev and I want all the udev support I can get to make things cooperate smoothly. But in the case of a problem, I'm very much depending on a static lvm binary on my system, since my /usr is on lvm and I know initramfs isn't up to recover many problems that might arise e.g. when upgrading boot loader or some other fundamental aspect. So I'd prefer a double compilation of lvm: dynamic with all the optional libraries thrown in, and static with only the bare minimum. How does this sound?
That said, I wonder what's wrong with my fix from comment #3 and comment #4. Do you object to this kind of fix, and if so for what reason? Or do you want to avoid allowing a configuration which is unsupported by upstream, even if it apparently works just fine?
Anything changed? I had the same problem with lvm2 compilation (readline static thin udev). But few hours ago I did another sync + -uDN world and package compiled nicely.
OK, so util-linux-2.25 was masked (cfdisk bug) and udev compiles nicely with util-linux-2.24. So REQUIRE_USE "static? ( !udev )" shouldn't be forced on systems with util-linux <= 2.24.
Martin, I agree with 12 and 13: I have /usr on an lvm, so I pretty much need lvm2 built with static. At the same time, I have no plans to switch to systemd (and I've read a few reports that eudev still has ... issues. ssuominen, I'm also not comfortable with masking udev on static lvm builds, and I'm not sure the argument "systemd doesn't support static" is convincing: it seems gentoo is doggedly holding on to udev precisely because it *doesn't* act like systemd. Is Martin's suggestion from #3 and #4 unworkable?
*** Bug 543406 has been marked as a duplicate of this bug. ***
(In reply to Martin von Gagern from comment #4) > With the following settings, all three packages emerged successfully: > > ==> /etc/portage/env/sys-apps/util-linux <== > CFLAGS="${CFLAGS} -Dmkdir_p=util_linux_mkdir_p" > CXXFLAGS="${CXXFLAGS} -Dmkdir_p=util_linux_mkdir_p" > > ==> /etc/portage/env/sys-fs/udev <== > CFLAGS="${CFLAGS} -Dmkdir_p=udev_mkdir_p" > CXXFLAGS="${CXXFLAGS} -Dmkdir_p=udev_mkdir_p" this fix works. After recompiling udev and util-linux, lvm2 compiles fine here with udev and static use-flag enabled. Please get this bug closed and add this to the corresponding ebuilds
[ebuild R ] sys-apps/util-linux-2.25.2-r2::gentoo USE="caps ncurses nls pam static-libs tty-helpers udev unicode -cramfs -fdformat -python (-selinux) -slang -suid -systemd {-test}" ABI_X86="(64) -32 (-x32)" PYTHON_SINGLE_TARGET="python2_7 -python3_3 -python3_4" PYTHON_TARGETS="python2_7 -python3_3 -python3_4" 0 KiB [ebuild R ] sys-fs/udev-216::gentoo USE="acl firmware-loader gudev introspection kmod static-libs -doc (-selinux)" ABI_X86="32 (64) (-x32)" 0 KiB [ebuild R ~] sys-fs/lvm2-2.02.109-r1::gentoo USE="readline static static-libs udev -clvm -cman -device-mapper-only -lvm1 -lvm2create_initrd (-selinux) -systemd -thin" 0 KiB
(In reply to Samuli Suominen from comment #11) > Note that systemd (udev) upstream doesn't support static linking, it's > configure.ac has... > > AS_IF([test "x$enable_static" = "xyes"], [AC_MSG_ERROR([--enable-static is > not supported by systemd])]) > > ...to prevent building of libudev.a, required by USE="static udev" > > So I'm not suprised by this bug. Perhaps we should add... > > REQUIRED_USE="static? ( !udev )" > > ...like sys-fs/cryptsetup got already REQUIRED_USE="static? ( !gcrypt )" wrt > bug 496612, comment #23 Erm, systemd is not the only udev provider. So this is not a solution. You are effectively blocking a usable configuration. Can you please revert this and fix the dependencies? It compiles perfectly fine with stable eudev.
I will apply this in 2 weeks, unless the maintainer speaks up. Either the systemd/udev maintainers fix their packages or the dependency has to be exactly like this. --- sys-fs/lvm2/lvm2-2.02.109-r1.ebuild +++ sys-fs/lvm2/lvm2-2.02.109-r1.ebuild @@ -14,8 +14,7 @@ SLOT="0" KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-linux ~x86-linux" IUSE="readline static static-libs systemd clvm cman lvm1 lvm2create_initrd selinux +udev +thin device-mapper-only" -REQUIRED_USE="device-mapper-only? ( !clvm !cman !lvm1 !lvm2create_initrd !thin ) - static? ( !udev )" #520450 +REQUIRED_USE="device-mapper-only? ( !clvm !cman !lvm1 !lvm2create_initrd !thin )" DEPEND_COMMON="clvm? ( cman? ( =sys-cluster/cman-3* ) =sys-cluster/libdlm-3* ) readline? ( sys-libs/readline ) @@ -38,7 +37,7 @@ >=sys-devel/binutils-2.20.1-r1 static? ( selinux? ( sys-libs/libselinux[static-libs] ) - udev? ( >=virtual/libudev-208:=[static-libs] ) + udev? ( sys-fs/eudev[static-libs] ) >=sys-apps/util-linux-2.16[static-libs] )"
(In reply to Julian Ospald (hasufell) from comment #21) > I will apply this in 2 weeks, unless the maintainer speaks up. > > Either the systemd/udev maintainers fix their packages or the dependency has > to be exactly like this. > > --- sys-fs/lvm2/lvm2-2.02.109-r1.ebuild > +++ sys-fs/lvm2/lvm2-2.02.109-r1.ebuild > @@ -14,8 +14,7 @@ > SLOT="0" > KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh > ~sparc ~x86 ~amd64-linux ~x86-linux" > IUSE="readline static static-libs systemd clvm cman lvm1 lvm2create_initrd > selinux +udev +thin device-mapper-only" > -REQUIRED_USE="device-mapper-only? ( !clvm !cman !lvm1 !lvm2create_initrd > !thin ) > - static? ( !udev )" #520450 > +REQUIRED_USE="device-mapper-only? ( !clvm !cman !lvm1 !lvm2create_initrd > !thin )" > > DEPEND_COMMON="clvm? ( cman? ( =sys-cluster/cman-3* ) > =sys-cluster/libdlm-3* ) > readline? ( sys-libs/readline ) > @@ -38,7 +37,7 @@ > >=sys-devel/binutils-2.20.1-r1 > static? ( > selinux? ( sys-libs/libselinux[static-libs] ) > - udev? ( >=virtual/libudev-208:=[static-libs] ) > + udev? ( sys-fs/eudev[static-libs] ) > >=sys-apps/util-linux-2.16[static-libs] > )" I'm going to be changing the symbol in eudev to _mkdir_p (or udev_mkdir_p or similar). This will be out in eudev-3.1.2 which I'll put on the tree soon.
> > I'm going to be changing the symbol in eudev to _mkdir_p (or udev_mkdir_p or > similar). This will be out in eudev-3.1.2 which I'll put on the tree soon. eudev-3.1.2, which I just added to the tree, fixes this issue.
(In reply to Anthony Basile from comment #23) > > > > I'm going to be changing the symbol in eudev to _mkdir_p (or udev_mkdir_p or > > similar). This will be out in eudev-3.1.2 which I'll put on the tree soon. > > eudev-3.1.2, which I just added to the tree, fixes this issue. it seems you forgot to push the ebuild, at least at https://packages.gentoo.org/package/sys-fs/eudev it doesn't show up and the latest sync doesn't include it
(In reply to Anthony Basile from comment #23) > > > > I'm going to be changing the symbol in eudev to _mkdir_p (or udev_mkdir_p or > > similar). This will be out in eudev-3.1.2 which I'll put on the tree soon. > > eudev-3.1.2, which I just added to the tree, fixes this issue. but it even compiles fine with eudev-1.10-r2 here, why?
(In reply to Herbert Wantesh from comment #24) > (In reply to Anthony Basile from comment #23) > > > > > > I'm going to be changing the symbol in eudev to _mkdir_p (or udev_mkdir_p or > > > similar). This will be out in eudev-3.1.2 which I'll put on the tree soon. > > > > eudev-3.1.2, which I just added to the tree, fixes this issue. > > it seems you forgot to push the ebuild, at least at > > https://packages.gentoo.org/package/sys-fs/eudev > > it doesn't show up and the latest sync doesn't include it Something went wrong. I pushed again. Please check that its showing up there.
(In reply to Julian Ospald (hasufell) from comment #25) > (In reply to Anthony Basile from comment #23) > > > > > > I'm going to be changing the symbol in eudev to _mkdir_p (or udev_mkdir_p or > > > similar). This will be out in eudev-3.1.2 which I'll put on the tree soon. > > > > eudev-3.1.2, which I just added to the tree, fixes this issue. > > but it even compiles fine with eudev-1.10-r2 here, why? it shouldn't, # readelf -sW libudev.a | grep mkdir_p 7: 0000000000000000 78 FUNC GLOBAL DEFAULT 1 mkdir_parents_label 10: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND mkdir_parents_internal 21: 0000000000000090 627 FUNC GLOBAL DEFAULT 1 mkdir_parents_internal 29: 0000000000000310 78 FUNC GLOBAL DEFAULT 1 mkdir_parents 31: 0000000000000360 165 FUNC GLOBAL DEFAULT 1 mkdir_p_internal 32: 0000000000000410 78 FUNC GLOBAL DEFAULT 1 mkdir_p The symbol is there.
(In reply to Anthony Basile from comment #27) > it shouldn't, > > # readelf -sW libudev.a | grep mkdir_p > 7: 0000000000000000 78 FUNC GLOBAL DEFAULT 1 > mkdir_parents_label > 10: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND > mkdir_parents_internal > 21: 0000000000000090 627 FUNC GLOBAL DEFAULT 1 > mkdir_parents_internal > 29: 0000000000000310 78 FUNC GLOBAL DEFAULT 1 mkdir_parents > 31: 0000000000000360 165 FUNC GLOBAL DEFAULT 1 mkdir_p_internal > 32: 0000000000000410 78 FUNC GLOBAL DEFAULT 1 mkdir_p > > The symbol is there. Yep and still compiles with sys-apps/util-linux-2.25.2-r2 and sys-fs/lvm2-2.02.109-r1 (after removing the broken REQUIRED_USE constraint ofc).
It's nice if eudev avoids the clash on its side, but I'm still wondering why you won't apply the solution from comment #4 for when users use the udev package. As far as I can see, noone has raised any objections to this yet, so I'd still see that as the proposed way to resolve this issue, unless someone provides an argument to the contrary.
Solution proposed in comment #4 and implemented for eudev in https://github.com/gentoo/eudev/commit/5e11fe2 works fine on my hardened amd64 machine with regular udev as well. Thanks to Martin von Gagern and Anthony Basile. It's been a year since the original solution was proposed here though. Can it be merged to the tree for udev users anytime soon, please?
maintainer timeout, I fixed it for eudev users: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9622ff0f299caf42398909ad7f788f7b7eaf43e2 it's up to udev maintainers if they care to fix broken static-libs support
Created attachment 414770 [details] emerge --info sys-apps/util-linux I hit a failure on util-linux-2.26.2 INFO: install ││abi_x86_64.amd64: running multilib-minimal_abi_src_install ││ERROR: install ││ERROR: sys-apps/util-linux-2.26.2::gentoo failed (install phase): ││ unable to read SONAME from libmount.so ││ │ │Call stack: ││ ebuild.sh, line 93: Called src_install ││ environment, line 4225: Called multilib-minimal_src_install │ environment, line 2646: Called multilib_foreach_abi 'multilib-minimal_abi_src_install' │ │ environment, line 2833: Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_install' │ │ environment, line 2534: Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_install' │ I fd │ environment, line 2532: Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_install' │ environment, line 575: Called multilib-minimal_abi_src_install │ environment, line 2636: Called multilib_src_install │ environment, line 3067: Called gen_usr_ldscript '-a' 'blkid' 'mount' 'smartcols' 'uuid' found this bug and fed from comment #4 "CFLAGS="${CFLAGS} -Dmkdir_p=util_linux_mkdir_p" emerge sys-apps/util-linux to root# Build succeeds. Emerge --info sys-apps/util-linux attached. Did not declare static.
So I'm not sure if there's anything left to be done here for lvm2. It sounds like there might be something to do here for util-linux but that should really be opened as a separate bug. Reopen if I'm wrong.
