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

From: Zdenek Kabelac <zkabelac@redhat.com>
To: Marcin Niestroj <m.niestroj@grinn-global.com>, dm-devel@redhat.com
Subject: Re: [RESEND PATCH v2] configure: Introduce --enable-symvers option
Date: Mon, 3 Sep 2018 16:42:28 +0200	[thread overview]
Message-ID: <c983376a-50fd-d807-7daf-e4508aac6009@redhat.com> (raw)
In-Reply-To: <20180831144817.31207-1-m.niestroj@grinn-global.com>

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