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???)
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' ?
So what's you plan how to solve backward compatibility - is i.e. 'uclibc'
always user in a way 'recompile everything from scratch' ??
Why is the system compiled with 'gcc' not supporting versioning?
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 ?
Zdenek
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
