[OpenAFS-devel] Build fails with gcc 9.1.1

Benjamin Kaduk kaduk@mit.edu
Tue, 30 Jul 2019 15:31:19 -0500


On Mon, Jul 29, 2019 at 01:35:11PM -0400, Chaskiel Grundman wrote:
> This may be due to bugs in gcc or the linker. The nest of reports is
> inconclusive (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490
> https://sourceware.org/bugzilla/show_bug.cgi?id=23411
> https://www.bountysource.com/issues/60348964-multiple-prevailing-defs-for-unused-variable-in-lto-mode
> )
> 
> It's likely that part of the problem is that some component didn't decide
> that the two different copies of liboafs_ubik.la were the same file and did
> not need to be processed independently:
> (adding -v after gcc to the actual libtool command)
> 
>  /usr/lib/gcc/x86_64-linux-gnu/8/collect2 -plugin
> /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so
> -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
> -plugin-opt=-fresolution=/tmp/ccoT0MYW.res -plugin-opt=-pass-through=-lgcc
> -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lpthread
> -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
> -plugin-opt=-pass-through=-lgcc_s -flto --build-id --eh-frame-hdr -m
> elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker
> /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro -o pt_util
> /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o
> /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o
> /usr/lib/gcc/x86_64-linux-gnu/8/crtbeginS.o -L/usr0/openafs/lib
> -L/usr/lib/gcc/x86_64-linux-gnu/8
> -L/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu
> -L/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib -L/lib/x86_64-linux-gnu
> -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
> -L/usr/lib/gcc/x86_64-linux-gnu/8/../../.. pt_util.o ptutils.o ptubik.o
> utils.o map.o >>>>../../src/ptserver/.libs/liboafs_prot.a
> /usr0/openafs/src/ubik/.libs/liboafs_ubik.a
> ../../src/ubik/.libs/liboafs_ubik.a<<<<
> /usr0/openafs/src/auth/.libs/liboafs_auth.a  ...

Perhaps relating to the difference between absolute and relative path for
the two incarnations.  Which might suggest some additional cleanup work to
be done, as well as your proposal...

-Ben