Red Hat Bugzilla – Bug 785399
ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality can not be used when making an executable; recompile with -fPIE and relink with -pie
Last modified: 2014-06-16 19:46:55 EDT
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):
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)
2. Run the following command:
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-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
File compiles and links normally.
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
GNU C Library stable release version 2.7, by Roland McGrath et al.
$ dpkg-query -W binutils
--- Additional comment from email@example.com on 2010-06-22 13:16:50 EDT ---
Works fine on Arch Linux x86_64 with the following:
$ pacman -Q gcc glibc binutils
--- Additional comment from firstname.lastname@example.org on 2010-06-23 03:41:36 EDT ---
--export-dynamic doesn't make sense in a static link.
--- Additional comment from email@example.com 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 firstname.lastname@example.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:
--- Additional comment from email@example.com 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:
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?
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:
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
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
> 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 ?
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.
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:
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)
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 ***