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
Summary: ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality can not be us...
Keywords:
Status: CLOSED DUPLICATE of bug 642999
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: 19
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: LVM and device-mapper development team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-28 17:07 UTC by Wulf C. Krueger
Modified: 2014-06-16 23:46 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 606830
Environment:
Last Closed: 2014-02-17 09:31:04 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Full build log (111.69 KB, text/plain)
2012-01-29 10:24 UTC, Wulf C. Krueger
no flags Details
Patch against 2.02.89 to fix this issue (3.11 KB, patch)
2012-01-29 11:25 UTC, Wulf C. Krueger
no flags Details | Diff

Description Wulf C. Krueger 2012-01-28 17:07:09 UTC
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.

Comment 1 Zdenek Kabelac 2012-01-28 19:48:45 UTC
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

Comment 2 Wulf C. Krueger 2012-01-28 20:25:30 UTC
That commit, which is included in LVM2-2.02.89, does *not* fix the problem.

Comment 3 Alasdair Kergon 2012-01-29 03:56:02 UTC
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.

Comment 4 Wulf C. Krueger 2012-01-29 10:23:20 UTC
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.

Comment 5 Wulf C. Krueger 2012-01-29 10:24:08 UTC
Created attachment 558136 [details]
Full build log

Comment 6 Wulf C. Krueger 2012-01-29 11:25:10 UTC
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.

Comment 7 Alasdair Kergon 2012-01-29 15:39:51 UTC
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.)

Comment 8 Wulf C. Krueger 2012-01-29 18:35:56 UTC
(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.

Comment 9 Alasdair Kergon 2012-01-29 19:42:06 UTC
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.

Comment 10 Alasdair Kergon 2012-01-29 19:48:15 UTC
(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.)

Comment 11 Alasdair Kergon 2012-01-29 20:05:54 UTC
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.

Comment 12 Wulf C. Krueger 2012-01-30 18:20:52 UTC
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!

Comment 13 Alasdair Kergon 2012-01-30 18:58:14 UTC
Do you have a snapshot in the VG and monitoring enabled?
strace dmeventd.static to watch if it does anything or not

Comment 14 Zdenek Kabelac 2012-01-30 19:25:22 UTC
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...

Comment 15 Wulf C. Krueger 2012-01-31 20:17:31 UTC
(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.

Comment 16 Alasdair Kergon 2012-01-31 21:02:00 UTC
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.

Comment 17 Zdenek Kabelac 2012-02-01 21:50:21 UTC
(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 ?

Comment 18 john.donnelly 2012-05-09 15:26:43 UTC
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  ?

Comment 19 john.donnelly 2012-05-09 15:59:24 UTC
(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

Comment 20 Wulf C. Krueger 2012-05-09 16:26:10 UTC
> 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.

Comment 21 Fedora End Of Life 2013-04-03 19:32:11 UTC
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

Comment 22 Kamaraju S. Kusumanchi 2013-07-28 19:03:58 UTC
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

Comment 23 Peter Rajnoha 2014-02-17 09:31:04 UTC

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


Note You need to log in before you can comment on or make changes to this bug.