This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Non-PIC call sequence in shared objects that call libmvec functions.
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: 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 09:02:45 -0800
- Subject: Re: Non-PIC call sequence in shared objects that call libmvec functions.
- Authentication-results: sourceware.org; auth=none
- References: <56BA11B9 dot 7010908 at redhat dot com>
On Tue, Feb 9, 2016 at 8:20 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> 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
>
Would you mind opening a glibc bug?
Thanks.
H.J.