[Bug lto/66014] New: 5.1 mingw64 fails to perform slim bootstrap-lto: ccEt8YNj.ltrans4.ltrans.o:<artificial>:(.text+0x628): undefined reference to `stpcpy'

[Bug lto/66014] New: 5.1 mingw64 fails to perform slim bootstrap-lto: ccEt8YNj.ltrans4.ltrans.o:<artificial>:(.text+0x628): undefined reference to `stpcpy'

[breedlove.matt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66014

            Bug ID: 66014
           Summary: 5.1 mingw64 fails to perform slim bootstrap-lto:
                    ccEt8YNj.ltrans4.ltrans.o:<artificial>:(.text+0x628):
                    undefined reference to `stpcpy'
           Product: gcc
           Version: 5.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: breedlove.matt at gmail dot com
  Target Milestone: ---

Created attachment 35461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35461&action=edit
save-temps and object files for pex-win32 and stpcpy

Following the fix in PR 65559 (though LTO didn't work at all previously), GCC
on mingw64 is unable to perform a slim bootstrap, dying when building
liblto_plugin-0.dll.  Normal -ffat-lto-object builds unaffected.

/bin/sh ./libtool --tag=CC --tag=disable-static  --mode=link
/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/./prev-gcc/xgcc
-B/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/./prev-gcc/
-B/mingw64/x86_64-w64-mingw32/bin/ -L/mingw64/x86_64-w64-mingw32/lib
-L/mingw64/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/include -B/mingw64/x86_64-w64-mingw32/bin/
-B/mingw64/x86_64-w64-mingw32/lib/ -isystem /mingw64/x86_64-w64-mingw32/include
-isystem /mingw64/x86_64-w64-mingw32/sys-include    -Wall -O2 -march=x86-64
-mtune=native -flto=jobserver -frandom-seed=1 -Wc,-static-libgcc -no-undefined
-bindir "/mingw64/bin/gcc-5.1.0" -module -bindir
/mingw64/lib/gcc/x86_64-w64-mingw32/5.1.0  -Wc,../libiberty/libiberty.a 
-Xcompiler '-static-libstdc++' -Xcompiler '-static-libgcc'
'-Wl,--stack,12582912' -o liblto_plugin.la -rpath
/mingw64/lib/gcc/x86_64-w64-mingw32/5.1.0 lto-plugin.lo
libtool: link: 
/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/./prev-gcc/xgcc
-B/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/./prev-gcc/
-B/mingw64/x86_64-w64-mingw32/bin/ -L/mingw64/x86_64-w64-mingw32/lib
-L/mingw64/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/include -B/mingw64/x86_64-w64-mingw32/bin/
-B/mingw64/x86_64-w64-mingw32/lib/ -isystem /mingw64/x86_64-w64-mingw32/include
-isystem /mingw64/x86_64-w64-mingw32/sys-include    -shared  .libs/lto-plugin.o
  -L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib  -march=x86-64 -mtune=native
-static-libgcc ../libiberty/libiberty.a -static-libstdc++ -static-libgcc
-Wl,--stack -Wl,12582912   -o .libs/liblto_plugin-0.dll
-Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker
.libs/liblto_plugin.dll.a
M:\mingw64\tmp\cc5tPjOg.ltrans4.ltrans.o:<artificial>:(.text+0x628): undefined
reference to `stpcpy'
collect2.exe: error: ld returned 1 exit status
Makefile:351: recipe for target 'liblto_plugin.la' failed
make[1]: *** [liblto_plugin.la] Error 1
make[1]: Leaving directory
'/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/lto-plugin'
Makefile:264: recipe for target 'all' failed
make: *** [all] Error 2


This is following the fix to GCC by including specific object files in archives
rather than the entire library.  The following shows that no symbols appear
within the slim objects for the (should be defined) stpcpy in stpcpy.o as well
as the undefined symbol in pex-win32.o

$ nm --plugin prev-lto-plugin/.libs/liblto_plugin-0.dll libiberty/pex-win32.o
         U _close
         U _dup
         U _errno
         U _get_osfhandle
         U _open
         U _pipe
         U _read
         U CloseHandle
         U CreateFileA
         U CreateProcessA
         U fdopen
00000000 T funcs
         U getenv
         U GetExitCodeProcess
         U GetVersionExA
00000000 T pex_init
         U pex_init_common
         U qsort
         U SetHandleInformation
         U WaitForSingleObject
         U xmalloc

$ nm -a libiberty/pex-win32.o

0000000000000000 b .bss
0000000000000000 d .data
0000000000000000 r .gnu.lto_.decls.1
0000000000000000 r .gnu.lto_.inline.1
0000000000000000 r .gnu.lto_.opts
0000000000000000 r .gnu.lto_.refs.1
0000000000000000 r .gnu.lto_.symbol_nodes.1
0000000000000000 r .gnu.lto_.symtab.1
0000000000000000 r .gnu.lto_argv_to_argc.1
0000000000000000 r .gnu.lto_argv_to_cmdline.1
0000000000000000 r .gnu.lto_backslashify.1
0000000000000000 r .gnu.lto_env_compare.1
0000000000000000 r .gnu.lto_find_executable.1
0000000000000000 r .gnu.lto_funcs.1
0000000000000000 r .gnu.lto_pex_init.1
0000000000000000 r .gnu.lto_pex_win32_close.1
0000000000000000 r .gnu.lto_pex_win32_exec_child.1
0000000000000000 r .gnu.lto_pex_win32_fdopenr.1
0000000000000000 r .gnu.lto_pex_win32_fdopenw.1
0000000000000000 r .gnu.lto_pex_win32_open_read.1
0000000000000000 r .gnu.lto_pex_win32_open_write.1
0000000000000000 r .gnu.lto_pex_win32_pipe.1
0000000000000000 r .gnu.lto_pex_win32_wait.1
0000000000000000 r .gnu.lto_spawn_script.1
0000000000000000 r .gnu.lto_std_suffixes.1
0000000000000000 r .gnu.lto_win32_spawn.1
0000000000000000 r .rdata$zzz
0000000000000000 t .text
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
0000000000000000 ? pex-win32.c


$ nm --plugin prev-lto-plugin/.libs/liblto_plugin-0.dll libiberty/stpcpy.o
M:\msys64-backup\mingw64\bin\nm.exe: libiberty/stpcpy.o: no symbols

$ nm -a libiberty/stpcpy.o

0000000000000000 b .bss
0000000000000000 d .data
0000000000000000 r .gnu.lto_.decls.1
0000000000000000 r .gnu.lto_.inline.1
0000000000000000 r .gnu.lto_.opts
0000000000000000 r .gnu.lto_.refs.1
0000000000000000 r .gnu.lto_.symbol_nodes.1
0000000000000000 r .gnu.lto_stpcpy.1
0000000000000000 r .rdata$zzz
0000000000000000 t .text
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
0000000000000000 ? stpcpy.c


The result is that when attempting to perform the final link of
liblto_plugin-0.dll, stpcpy.o doesn't get pulled in.  Putting the stpcpy.o
object file after libiberty.a such as the following, however, works perfectly
fine:


./libtool --tag=CC --tag=disable-static  --mode=link
/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/./prev-gcc/xgcc
-B/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/./prev-gcc/
-B/mingw64/x86_64-w64-mingw32/bin/ -L/mingw64/x86_64-w64-mingw32/lib
-L/mingw64/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/include -B/mingw64/x86_64-w64-mingw32/bin/
-B/mingw64/x86_64-w64-mingw32/lib/ -isystem /mingw64/x86_64-w64-mingw32/include
-isystem /mingw64/x86_64-w64-mingw32/sys-include    -Wall -O2 -march=x86-64
-mtune=native  -flto=jobserver -frandom-seed=1 -Wc,-static-libgcc -no-undefined
-bindir "/mingw64/bin/gcc-5.1.0" -module -bindir
/mingw64/lib/gcc/x86_64-w64-mingw32/5.1.0  -Wc,../libiberty/libiberty.a
-Wc,../libiberty/stpcpy.o  -Xcompiler '-static-libstdc++' -Xcompiler
'-static-libgcc' '-Wl,--stack,12582912' -o liblto_plugin.la -rpath
/mingw64/lib/gcc/x86_64-w64-mingw32/5.1.0 lto-plugin.lo

[Bug lto/66014] 5.1 mingw64 fails to perform slim bootstrap-lto: ccEt8YNj.ltrans4.ltrans.o:<artificial>:(.text+0x628): undefined reference to `stpcpy'

[breedlove.matt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66014

--- Comment #1 from Matt Breedlove <breedlove.matt at gmail dot com> ---
This issue is still present on 5.1.0 and trunk.  The issue seems to be related
to libiberty's implementation of stpcpy being replaced with the GCC builtin and
then causing linker errors due to that symbol not being defined when attempting
to link lto-plugin.

Passing in -fno-builtin-stpcpy when building libiberty has resolved this for me
and allows the build to progress but I'm unsure if there is any other potential
fallout from similar issues.

[Bug lto/66014] 5.1 mingw64 fails to perform slim bootstrap-lto: ccEt8YNj.ltrans4.ltrans.o:<artificial>:(.text+0x628): undefined reference to `stpcpy'

[rainer@emrich-ebersheim.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66014

Rainer Emrich <rainer@emrich-ebersheim.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rainer@emrich-ebersheim.de

--- Comment #2 from Rainer Emrich <rainer@emrich-ebersheim.de> ---
Confirmed, issue still present.

[Bug lto/66014] 5.1 mingw64 fails to perform slim bootstrap-lto: ccEt8YNj.ltrans4.ltrans.o:<artificial>:(.text+0x628): undefined reference to `stpcpy'

[breedlove.matt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66014

--- Comment #3 from Matt Breedlove <breedlove.matt at gmail dot com> ---
Created attachment 36166
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36166&action=edit
Patch to bypass sys_siglist and disable stpcpy builtin during bootstrap

I'm currently using this patch which overrides sys_siglist detection in
addition to the stpcpy built-in when building libiberty which prevents lto
bootstrapping.

sys_siglist causes failures in both slim and fat lto bootstraps in the later
stages while the stpcpy issue remains present only within slim bootstrapping.