I'm filing this bug against Fedora as there doesn't seem to be an LVM2 product, unfortunately. The issue is still unresolved and needs to be fixed in LVM2 itself, regardless of the Fedora version. The comments in the original bug still apply as quoted below. +++ This bug was initially created as a clone of Bug #606830 +++ Description of problem: static linkage doesn't work with binutils 2.6.20 Version-Release number of selected component (if applicable): binutils-2.20.51.0.2-20.fc13.x86_64 How reproducible: Create a sample file and try to compile it with -static and -Wl,--export-dynamic flags. Steps to Reproduce: 1. Create a file with the following contents: int main(int argc, char **argv) { return 0; } 2. Run the following command: gcc -static -Wl,--export-dynamic test.c Actual results: /usr/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/libc.a(strcmp.o)' can not be used when making an executable; recompile with -fPIE and relink with -pie collect2: ld returned 1 exit status Expected results: File compiles and links normally. Additional info: Reproduced both with Fedora 13 x86 and Fedora 13 x86_64. Reproduced when using gcc and gcc34 compilers. Here is the similar problem for Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584607 Same scenario works fine on Debian lenny x86: $ gcc --version gcc (Debian 4.3.2-1.1) 4.3.2 $ /lib/libc.so.6 GNU C Library stable release version 2.7, by Roland McGrath et al. $ dpkg-query -W binutils binutils 2.18.1~cvs20080103-7 --- Additional comment from victor.leschuk on 2010-06-22 13:16:50 EDT --- Works fine on Arch Linux x86_64 with the following: $ pacman -Q gcc glibc binutils gcc 4.5.0-6 glibc 2.12-2 binutils 2.20.1-3 --- Additional comment from schwab on 2010-06-23 03:41:36 EDT --- --export-dynamic doesn't make sense in a static link. --- Additional comment from tomash.brechko on 2011-02-09 11:57:44 EST --- FIY, the reason why strcmp is dynamic is described in http://udrepper.livejournal.com/20948.html section "Automatic use of optimized function". --- Additional comment from triage.org on 2011-06-01 11:54:39 EDT --- This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping --- Additional comment from triage.org on 2011-06-27 14:44:40 EDT --- Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
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 ***