[dm-devel] [RESEND PATCH v2] configure: Introduce --enable-symvers option

Marcin Niestrój m.niestroj at grinn-global.com
Wed Sep 5 11:03:13 UTC 2018


Hi Zdenek,

Zdenek Kabelac <zkabelac at redhat.com> 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




More information about the dm-devel mailing list