Symbol conflict when building lvm2 against libudev.a

[floppym]

systemd version the issue has been seen with
v249

Used distribution
Gentoo

CPU architecture issue was seen on
x86_64

Details
I am attempting to build lvm2 with --enable-static_link.
udev was built with -Dstatic-libudev=true

Linking the lvm.static binary fails due to a conflicting symbol version that is defined in both libudev.a and the lvm2 sources.

    [CC] lvm.static
x86_64-pc-linux-gnu-gcc -O2 -pipe -march=amdfam10 -fPIC -O2 -Wl,--as-needed -L./daemons/dmeventd -L../daemons/dmeventd -Wl,--no-export-dynamic -static -L../libdm/ioctl \
        -o lvm.static command.o dumpconfig.o formats.o lvchange.o lvconvert.o lvconvert_poll.o lvcreate.o lvdisplay.o lvextend.o lvmcmdline.o lvmdevices.o lvmdiskscan.o lvpoll.o lvreduce.o lvremove.o lvrename.o lvresize.o lvscan.o polldaemon.o pvchange.o pvck.o pvcreate.o pvdisplay.o pvmove.o pvmove_poll.o pvremove.o pvresize.o pvscan.o reporter.o segtypes.o tags.o toollib.o vgcfgbackup.o vgcfgrestore.o vgchange.o vgck.o vgcreate.o vgdisplay.o vgexport.o vgextend.o vgimport.o vgimportclone.o vgimportdevices.o vgmerge.o vgmknodes.o vgreduce.o vgremove.o vgrename.o vgscan.o vgsplit.o lvm-static.o ../lib/liblvm-internal.a ../libdaemon/client/libdaemonclient.a ../device_mapper/libdevice-mapper.a ../base/libbase.a -ldevmapper-event -L../libdm/ioctl -ldevmapper -lreadline   -lblkid  -laio  -ludev   -lm -lpthread  -ludev -lrt -pthread  -lblkid  -lm -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libudev.a(src_basic_util.c.o): in function `version':
(.text.version+0x0): multiple definition of `version'; lvmcmdline.o:lvmcmdline.c:(.text+0x4400): first defined here
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:145: lvm.static] Error 1

I am aware that the systemd project has no love for static linking, but I wanted to raise the issue in case there is some easy solution.

[poettering]

not sure we should do anything about this. We are very careful with marking all symbols we export with export info. This doesn't work with static libs, obviously, but not sure we should care. If you are asking us to rename all our internal symbols that have names that could conflict, then no way, that's not going to happen.

I think we should just revert 70848ec as unsupportable.

[poettering]

/cc @davide125 @keszybz

[davide125]

I just checked and we still rely on this on our end, but we don't build with lvm2 support so we never noticed this issue. When we hit a similar thing for MurmurHash2, we worked around it by setting -DMurmurHash2=systemd_MurmurHash2 in CPPFLAGS; you may want to try a similar approach here and see if it helps.

I'm all for making it more clear that static builds aren't officially supported, but I'd love to keep 70848ec in if possible as it makes our life a lot easier.

[floppym]

So a kludgy workaround would be to rename specific symbols in libudev.a using objcopy.

For example, to resolve this conflict with lvm2, we could do this:

objcopy --redefine-sym version=_systemd_version libudev.a

A more general workaround would be to write a script to prefix all symbols that are marked with "hidden" visibility.

I'm guessing that's not the sort of workaround you would want to support upstream?

I'm also ok with dropping support for building libudev.a; Gentoo doesn't really rely on it, but it will make some of our users unhappy.

[DerDakon]

I ran into this independently, see #20621. That name is just too generic for an exported symbol IMHO.

[floppym]

That name is just too generic for an exported symbol IMHO.

The version symbol isn't exported. It just that static libs are too stupid to know the difference between an exported and a hidden symbol.

[poettering]

Anyway, let's close this. If you want to make static linking work, then please work with the linker people to add a way to add namespacing to static linking. But we are simply not going to rename all our internal symbols.