Hi Zdenek, Zdenek Kabelac <zkabelac@xxxxxxxxxx> writes: > Dne 31.8.2018 v 16:48 Marcin Niestroj napsal(a): >> Only few libc (e.g. glibc) libraries support full symbol version >> resolution in runtime. There are lot of standard libraries that do not >> support that, such as dietlibc, musl and uclibc. Hence there is no >> reason to generate symbol versions when compiling against them. > > Hi > > Before going into depth of patch itself - I'd like to get clear first > what is wrong with existing solution. > > #if defined(__GNUC__) > > was supposed to be protecting against problematic usage - but it's > more towards 'gcc' compiler usage - where the version is tied to > compiler infrastructure. > > So now you say that other libraries do not support symbol versioning > at all (so I'm quite wondering how they are able to handle backward > compatibility???) [1] presents a general comparison of musl, uclibc, dietlibc and glibc. Please take a look at "ABI and versioning comparison" section. Some libcs do not support backward compatibility at all, which means that upgrade of libc requires upgrade of all executables. These libraries are often used in tiny embedded devices (where binary size matters), so only full system upgrade is often implemented. Regarding symbol versioning... uclibc implementation of dynamic linker ignores symbol version at all. It just searches for first occurance of a symbol, which is often the oldest symbol version. musl on the other hand is aware of symbol versioning, but I am not sure what is the logic there. For the system I compiled libdevmapper.so it turns out that the newest symbols were used by musl. [1] http://www.etalabs.net/compare_libcs.html > > One would have to always introduce completely NEW symbols?? > > >> Additionally libdevmapper.so was broken when compiled against >> uclibc. Runtime linker loader caused calling dm_task_get_info_base() >> function recursively, leading to segmentation fault. >> >> Introduce --enable-symvers[=STYLE] option, which allows to choose >> between gnu and disabled symbol versioning. By default gnu symbol >> versioning is used to provide backward compatibility. >> __GNUC__ check is replaced now with GNU_SYMVER, which is generated by >> configure script. Additionally ld version script is included only in >> case of gnu option, which slightly reduces output size. > > Yep - the idea was to support always 'last symbol' for compilers which > do not support symbol versioning. > > But your case seems to be you use 'gcc' compiler, > but surrouding libraries are not 'versioning-aware' ? My specific case, which I want to solve, is building GNU/Linux system from scratch using Buildroot [2] build system. Full image is build always from scratch, Buildroot does not support building just parts (packages/libraries) of an image. Hence my idea was to add build-time option, which Buildroot would always use (--disable-symvers) to build libdevmapper with musl and uclibc libraries. [2] https://buildroot.org/ > > So what's you plan how to solve backward compatibility - is i.e. > 'uclibc' always user in a way 'recompile everything from scratch' ?? Yes, always recompile everything (at least new library users). > > Why is the system compiled with 'gcc' not supporting versioning? That is because symbol versioning support relies on both gcc (or even binutils) and libc (runtime linker). Simple runtime linker (non aware of GNU symbol versions) just picks first symbol with exact name. This is how uclibc does that. musl on the other hand parses GNU version sections in shared libraries and chooses non `hidden` (hidden are non-default) symbols. glibc does proper symbol versioning, i.e. it checks if referenced version matches defined version. I have also checked, that bionic (Android libc) is aware of symbol versioning from around 2015. > > What is the plan how to resolve binary backward compatibility here? > (as you clearly cannot run 'old compiled binary' with new build > libdm if you provide only latest symbols in some cases) - is the 'I > don't care' policy applied regularly on such system ? Such systems should atomically replace libraries with all their users. These systems developers should explicitly request non versioned libraries, which can be achieved with introduced `--disable-symvers` option. This option is implemented similar as gcc libraries. > > > Zdenek -- Regards, Marcin -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
