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 _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel