This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Non-PIC call sequence in shared objects that call libmvec functions.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>, "Zamyatin, Igor" <igor dot zamyatin at intel dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Tue, 9 Feb 2016 11:20:09 -0500
- Subject: Non-PIC call sequence in shared objects that call libmvec functions.
- Authentication-results: sourceware.org; auth=none
Igor,
Shouldn't this be a PIC call sequence to support
creating shared objects that call through the alias?
diff --git a/sysdeps/x86_64/fpu/svml_finite_alias.S b/sysdeps/x86_64/fpu/svml_finite_alias.S
index 0062fe4..61725b7 100644
--- a/sysdeps/x86_64/fpu/svml_finite_alias.S
+++ b/sysdeps/x86_64/fpu/svml_finite_alias.S
@@ -23,7 +23,7 @@
#define ALIAS_IMPL(alias, target) \
ENTRY (alias); \
- call target; \
+ jmp target@plt; \
ret; \
END (alias)
With GCC6 generating vectorized calls now we're seeing package build
failures because having shared libraries call these entry points fails
with the following:
/usr/bin/ld: /usr/lib64/libmvec_nonshared.a(svml_finite_alias.oS):
relocation R_X86_64_PC32 against undefined symbol `_ZGVbN2v_log@@GLIBC_2.22'
can not be used when making a shared object; recompile with -fPIC
What is the right fix here?
Cheers,
Carlos.