Skip to content
Commit f8f9a272 authored by Adhemerval Zanella Netto's avatar Adhemerval Zanella Netto Committed by Adhemerval Zanella
Browse files

i386: Fix build with --enable-fortify=3



The i386 string routines provide multiple internal definitions
for memcpy, memmove, and mempcpy chk routines:

  $ objdump -t libc.a | grep __memcpy_chk
  00000000 g     F .text  0000000e __memcpy_chk
  00000000 g     F .text  00000013 __memcpy_chk
  $ objdump -t libc.a | grep __mempcpy_chk
  00000000 g     F .text  0000000e __mempcpy_chk
  00000000 g     F .text  00000013 __mempcpy_chk
  $ objdump -t libc.a | grep __memmove_chk
  00000000 g     F .text  0000000e __memmove_chk
  00000000 g     F .text  00000013 __memmove_chk

Although is not an issue for normal static builds, with fortify=3
glibc itself might use the fortify chk functions and thus static
build might fail with multiple definitions.  For instance:

x86_64-glibc-linux-gnu-gcc -m32 -march=i686 -o [...]math/test-signgam-uchar-static -nostdlib -nostartfiles -static -static-pie [...]
x86_64-glibc-linux-gnu/bin/ld: [...]/libc.a(mempcpy-ia32.o):
in function `__mempcpy_chk': [...]/glibc-git/string/../sysdeps/i386/i686/mempcpy.S:32: multiple definition of `__mempcpy_chk';
[...]/libc.a(mempcpy_chk-nonshared.o):[...]/debug/../sysdeps/i386/mempcpy_chk.S:28: first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [../Rules:298:

There is no need for mem*-nonshared.S, the __mem*_chk routines
are already provided by the assembly routines.

Checked on i686-linux-gnu with gcc 13 built with fortify=1,2,3 and
without fortify.
Reviewed-by: default avatarCarlos O'Donell <carlos@redhat.com>
parent df43ea48
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment