lib.o:(*IND*+0x0): multiple definition of `efi_set_variable'

[floppym]

I'm hitting a weird failure when building using ld.bfd without -flto in CFLAGS. Adding -flto lets it work.

This is with gcc-5.4.0 and binutils-2.26.1.

floppym@naomi efivar % CFLAGS= make efivar
make -C src efivar
make[1]: Entering directory '/home/floppym/src/efivar/src'
make -f /home/floppym/src/efivar/src/Make.deps deps SOURCES="crc32.c creator.c disk.c gpt.c linux.c loadopt.c dp.c dp-acpi.c dp-hw.c dp-media.c dp-message.c efivarfs.c error.c export.c guid.c guids.S guid-symbols.c lib.c vars.c makeguids.c guid.c include/efivar/efivar-guids.h include/efivar/efivar.h include/efivar/efiboot.h include/efivar/efiboot-loadopt.h include/efivar/efivar-dp.h include/efivar/efiboot-creator.h include/efivar/efivar-guids.h guid-symbols.c efivar.c"
make[2]: Entering directory '/home/floppym/src/efivar/src'
make[2]: Nothing to be done for 'deps'.
make[2]: Leaving directory '/home/floppym/src/efivar/src'
gcc  -I/home/floppym/src/efivar/src/include/efivar/  -specs=/home/floppym/src/efivar/gcc.specs   -L.       -shared \
  -Wl,-soname,libefivar.so.1 \
  -Wl,--version-script=libefivar.map \
  -o libefivar.so dp.o dp-acpi.o dp-hw.o dp-media.o dp-message.o efivarfs.o error.o export.o guid.o guids.o guid-symbols.o lib.o vars.o -ldl -lpopt
lib.o:(*IND*+0x0): multiple definition of `efi_set_variable'
lib.o:lib.c:(.text+0x463): first defined here
collect2: error: ld returned 1 exit status
make[1]: *** [/home/floppym/src/efivar/Make.rules:20: libefivar.so] Error 1
make[1]: Leaving directory '/home/floppym/src/efivar/src'
make: *** [Makefile:21: efivar] Error 2

[superm1]

So the most obvious solution is:

Index: efivar-30/Make.rules
===================================================================
--- efivar-30.orig/Make.rules
+++ efivar-30/Make.rules
@@ -18,6 +18,7 @@ include $(TOPDIR)/Make.version

 %.so :
    $(CCLD) $(ccldflags) $(CPPFLAGS) $(SOFLAGS) \
+     -Wl,-z,muldefs \
      -Wl,-soname,$@.1 \
      -Wl,--version-script=$(MAP) \
      -o $@ $^ $(LDLIBS)

I only see the one definition in lib.c and the version script only refers in one version, so adding that is probably masking something else odd.

So whether that's the right solution I guess is up to @vathpela

[vathpela]

Huh, that might actually work. FWIW this appears to be a compiler bug (the multiple definitions are symbol versioning, which should just work), and it goes away with -flto.

But I'm totally okay working around it with -z muldefs. I'd rather put it in ccldflags, though.