diff mbox

Non-PIC call sequence in shared objects that call libmvec functions.

Message ID 56BA11B9.7010908@redhat.com
State New
Headers show

Commit Message

Carlos O'Donell Feb. 9, 2016, 4:20 p.m. UTC 
Igor,

Shouldn't this be a PIC call sequence to support
creating shared objects that call through the 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.

Comments

H.J. Lu Feb. 9, 2016, 5:02 p.m. UTC | #1 
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.
Carlos O'Donell Feb. 9, 2016, 5:51 p.m. UTC | #2 
On 02/09/2016 12:02 PM, H.J. Lu wrote:
> 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?

Bug 19590 - Fail to build shared objects that use libmvec.so functions. 
https://sourceware.org/bugzilla/show_bug.cgi?id=19590

Cheers,
Carlos.
diff mbox

Patch

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)