Bug 785399

Assuming this has been already fixed by upstream commit:

https://www.redhat.com/archives/lvm-devel/2011-November/msg00080.html

And should be fixed with  lvm2-2.02.89-2.fc17.x86_64

That commit, which is included in LVM2-2.02.89, does *not* fix the problem.

Please provide specific details!

The quotes are from a binutils bugzilla, not an lvm2 one.


What are you doing in order to obtain this error?

Which distro are you using and what version?  Which architecture?

What 'configure' line?  What versions of other relevant packages?

etc. etc.

Basically, the "steps to reproduce" from the first original comment will show the problem. The product at the time was indeed binutils but the problem lay and still lies within LVM2. Anyway, here we go with the data you asked for:

I'm trying to build LVM2-2.02.89 from source using the following configure options:

./configure --prefix=/usr --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --docdir=/usr/share/doc/lvm2-2.02.89 --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --enable-fast-install --libdir=//lib64 --exec-prefix=/ --libdir=/lib64 --enable-applib --enable-cmdlib --enable-lvmetad --enable-pkgconfig --enable-readline --enable-static_link --enable-udev_rules --enable-udev_sync --with-clvmd-pidfile=/run/clvmd.pid --with-cmirrord-pidfile=/run/cmirrord.pid --with-dmeventd-pidfile=/run/dmeventd.pid --with-default-locking-dir=/run/lock/lvm --with-default-run-dir=/run/lvm --with-udevdir=/lib64/udev/rules.d --with-usrlibdir=/usr/lib64 --disable-nls --disable-selinux --enable-dmeventd --enable-fsadm

Arch is x86_64 as can be seen above. I'm a packager for Exherbo Linux which shouldn't matter as we don't deviate from upstream versions of the relevant packages:

gcc-4.6.2
GNU C Library stable release version 2.13, by Roland McGrath et al.
GNU ld (GNU Binutils) 2.21.1

In the full build log I'm going to attach next, please look at line 1545 and notice the use of "-Wl,--export-dynamic -static" which causes this issue.

Created attachment 558136 [details]
Full build log

Created attachment 558143 [details]
Patch against 2.02.89 to fix this issue

The attached patch introduces STATIC_LDFLAGS (comprised only of "-Wl,--no-export-dynamic", atm) and adds it to the relevant calls.

From the configure line, that's then a known problem: we don't support 
--enable-static_link with --enable-dmeventd / --enable-udev_sync
and I didn't think it was worth the effort involved in offering such support.

Does your distribution have some specific reason for needing static linking of dmeventd?

Have you tested the binaries the --no-export-dynamic patch builds?  (I didn't think that would work.)

(In reply to comment #7)
> From the configure line, that's then a known problem: we don't support 
> --enable-static_link with --enable-dmeventd / --enable-udev_sync
> and I didn't think it was worth the effort involved in offering such support.

Ah, ok, would be nice if that was documented somewhere.

> Does your distribution have some specific reason for needing static linking of
> dmeventd?

Basically, we're mostly interested in statically linked versions of lvm and dmsetup.

> Have you tested the binaries the --no-export-dynamic patch builds?  (I didn't
> think that would work.)

Yes, of course. They're working fine here.

Your patch doesn't work for me, as expected.

  vg2-lvol1: event registration failed: 27953:3 libdevmapper-event-lvm2snapshot.so dlopen failed: /lib64/libdevmapper-event-lvm2.so.2.02: undefined symbol: dmeventd_debug
  vg2/snapshot0: snapshot segment monitoring function failed.

(vg2/lvol1 is a snapshot, dmeventd.static is running, and vgchange -ay gives that error)

But you confirm you don't need dmeventd.static, so I think a cleaner fix would be just not to attempt to build dmeventd.static at all, even when static_link is specified.

(It fails because we need --export-dynamic so that the dynamic libs that dmeventd loads with dlopen() can locate their symbols, and without dlopen(), dmeventd is useless.  A proper dmeventd.static would have all possible libs built-in instead of dlopened, and as I said, I don't see any point in doing that at the moment.)

BTW Dropping dmeventd.static means that lvm.static will use the dynamic dmeventd, which begs the question 'If dynamic libraries are going to have to be available for dmeventd, why not use them with lvm too?'

So the only supportable configurations at the moment are either where you don't need any dmeventd monitoring (so you configure without it) OR where you're using static lvm/dmsetup during initrd without dmeventd monitoring and then starting up dynamic dmeventd/lvm from the main filesystem later during boot.  At the moment, that case needs two builds doing with different configure lines.

Hm... Running dmeventd.static -ddd -f and vgchange -ay doesn't log any errors to syslog here. I wonder why it works for me but not for you; maybe your dmeventd.static was linked against a different version of glibc than the one you used during your test run? (Doesn't sound very likely, though. :) )

Anyway, your remark from Comment 10 about not using dlopen at all is very valid, indeed, and, thus, Comment 11 follows suit.

For now, I'm going to follow your advice and build things twice and drop the patch (even though it works for me) to be on the safe(r) side of things.

It would be nice, though, if you could maybe add the gist of Comment 11 to LVM2's docs so that others can benefit from it, too.

Thanks for your time and explanations!

Do you have a snapshot in the VG and monitoring enabled?
strace dmeventd.static to watch if it does anything or not

To get dmeventd.static working - we would need to link all lvm2 plugins as libs - which might in fact actually take less memory (compare with our runtime memory support) - of course dmraid plugin would still not work this way....

But I still miss the point why is the static linking support needed ?
Debugging is quite easy with dynamic linkage, dracut is also using dynamic version since it safe space in ramdisk...

(In reply to comment #13)
> Do you have a snapshot in the VG and monitoring enabled?
> strace dmeventd.static to watch if it does anything or not

Ok, I could reproduce your result now - dmeventd.static doesn't actually work. During my initial test, it started but wasn't actually doing anything.

(In reply to comment #14)
> But I still miss the point why is the static linking support needed ?

In cases of potentially highly important system components like LVM2, I generally prefer to provide both dynamically *and* statically linked versions just in case (e. g. during recovery scenarios) the shared libs aren't available.
There are weird configurations out there and while I certainly don't intend to support them all, statically linked binaries of some core utilities are usually easy to provide.

OK, for recovery there's definitely no need for dmeventd.static.
So let's go with the option of disabling attempts to build dmeventd.static, and concentrate just on providing lvm and dmsetup as static.

(In reply to comment #15)
> (In reply to comment #13)
> > Do you have a snapshot in the VG and monitoring enabled?
> > strace dmeventd.static to watch if it does anything or not
> 
> Ok, I could reproduce your result now - dmeventd.static doesn't actually work.
> During my initial test, it started but wasn't actually doing anything.
> 
> (In reply to comment #14)
> > But I still miss the point why is the static linking support needed ?
> 
> In cases of potentially highly important system components like LVM2, I
> generally prefer to provide both dynamically *and* statically linked versions
> just in case (e. g. during recovery scenarios) the shared libs aren't
> available.
> There are weird configurations out there and while I certainly don't intend to
> support them all, statically linked binaries of some core utilities are usually
> easy to provide.

IMHO it's much better to focus energy here in providing recovery environment with usable dynamic libraries - since there is a lot of shared code between all tools in such environment - thus linking each binary staticaly makes such rescue image much bigger compared with version that uses dynamic executables (look at the Fedora) -   do you have static version of udev, mknod, mount,mv, rm... and many other important tools ?

Hello.

I am interest in following this to a resolution as we 
use LVM2 built in a static also. 

Are there going to be published solution to this in an
upcoming releaseof lvm2  ?

(In reply to comment #6)
> Created attachment 558143 [details]
> Patch against 2.02.89 to fix this issue
> 
> The attached patch introduces STATIC_LDFLAGS (comprised only of
> "-Wl,--no-export-dynamic", atm) and adds it to the relevant calls.

Hi,

I applied this patch, ran the above ./configure + args 
and I don't see a lvm-static produced, or a lvm static:
# cd tools
# file lvm
lvm: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

> I applied this patch, ran the above ./configure + args 

Please do read bugs you comment on. In this case, specifically comments 9 ff.

In short: My patch makes things compile but fail at runtime. It's *wrong*.

Personally, I've come to agree with Zdenek (comment 17): Dynamic libs, even in constrained environment, are the way to go.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

FWIW, I am able to reproduce this problem on a machine running a combination of Debian Squeeze and Wheezy

rajulocal@hogwarts:~/x$ cat test.c 
int main(int argc, char **argv)
{
	return 0;
}

rajulocal@hogwarts:~/x$ gcc -static -Wl,--export-dynamic test.c 
/usr/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libc.a(strcmp.o)' can not be used when making an executable; recompile with -fPIE and relink with -pie
collect2: error: ld returned 1 exit status

rajulocal@hogwarts:~/x$ dpkg -l gcc binutils libc6
ii  binutils                                       2.22-8                       amd64                        GNU assembler, linker and binary utilities
ii  gcc                                            4:4.7.2-1                    amd64                        GNU C compiler
ii  libc6:amd64                                    2.13-38                      amd64                        Embedded GNU C Library: Shared libraries
ii  libc6:i386                                     2.13-38                      i386                         Embedded GNU C Library: Shared libraries

rajulocal@hogwarts:~/x$ uname -a
Linux hogwarts 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux

*** This bug has been marked as a duplicate of bug 642999 ***