[PATCH] gmp: compile with -DPIC to use correct asm code

Stijn Tintel stijn at linux-ipv6.be
Fri Mar 12 10:34:13 GMT 2021


On 11/03/2021 23:46, Eneas U de Queiroz wrote:
> The library is always compiled with $(FPIC) (-fPIC or -fpic), even for
> the static library.
>
> There are some assembly sources that decide whether or not to enable
> PIC code by checking if PIC is defined.  It counts on libtool to define
> it, but libtool does it only when producing code for the dynamic
> library, while we need it for both.
>
> Ensure it is defined by adding it to CFLAGS next to $(FPIC).
>
> It avoids linking errors with strongswan on x86_64:
>
> ld: libgmp.a(bdiv_q_1.o): relocation R_X86_64_PC32 against symbol
> `__gmp_binvert_limb_table' can not be used when making a shared object;
> recompile with -fPIC
>
> Cc: Stijn Tintel <stijn at linux-ipv6.be>
> Signed-off-by: Eneas U de Queiroz <cotequeiroz at gmail.com>
> ---
>
> There's an error on one architecture, and all others work fine without
> this, so I'm uneasy changing this and then breaking stuff that was
> working fine otherwise.  However, it feels wrong to me to generate PIC
> code from C files, but not use it in asm sources, which is essentially
> what I am changing here.
>
> I've looked at asm sources for different chitectures, and there are
> checks for PIC in: arm64, arm, x86_64, x86, and ppc asm sources, but the
> error only appears on x86_64.
>
> For most CPUs, ifdef(`PIC'), is just used to do different definitions of
> LEA (Load Effective Address).  However, both x86 and x86_64 have many
> other checks.
>
> I've looked at bdiv_q_1.asm for different CPUs, and they all do some
> form of LEA(binvert_limb_table), except for x86, where it will do it
> only when PIC is defined.  That may explain why x86_64 is affected, and
> x86 is not.
>
> I have not investigated further details.
>
> Alternatively, we can define it only for x86_64, which is where we know
> there's a build failure with the linker asking to recompile with -fPIC.
>
I'm sorry, but I lack the knowledge to review this.

Stijn




More information about the openwrt-devel mailing list