https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83452
--- Comment #7 from dave.anglin at bell dot net --- On 2017-12-18 2:48 PM, rguenther at suse dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83452 > > --- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- > On December 18, 2017 7:38:17 PM GMT+01:00, "dave.anglin at bell dot net" > <gcc-bugzi...@gcc.gnu.org> wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83452 >> >> --- Comment #5 from dave.anglin at bell dot net --- >> On 2017-12-18 10:37 AM, rguenth at gcc dot gnu.org wrote: >>> Can you check if the attached helps? It makes those local symbols >> defined >>> instead >>> (in the very first section we preserve, retaining the NULL name). >> The patch helps significantly. However, the final link fails with the >> message: >> >> ld: Unsatisfied hidden symbol "gnu_lto_v1". Symbol was referenced from >> file /var/tmp//ccG1CcR8debugobj >> 1 errors. >> collect2: fatal error: ld returned 1 exit status >> >> HP linker doesn't like undefined weak symbols. > Hmm, that sounds like a bug in the HP linker. I guess there's no chance of > getting Bugfixes for hpux issues? Nope. It's a long standing issue. There is a ld option, "+allowunsats", but the dynamic linker will generate an error if the symbol isn't resolved at runtime. > > This was changed for the Solaris linker BTW. Which didn't like UNDEF globals > that cannot be resolved. Using weak should in theory work... If gcc doesn't want to keep this symbol, maybe I can define it in libgcc. We have a collection of nop routines in libgcc_stub.a to provide definitions for various weak undefined functions. > >> Symbol was defined in save_6.s as follows: >> >> .section .bss >> __gnu_lto_v1 .comm 1 >> .ident "GCC: (GNU) 8.0.0 20171215 (experimental) [trunk >> revision 255670]" >> >> It's not defined in save_6.exe.ltrans0.s.
