Re:Re: is there plan to support 'linker namespace' in glib?

[zhuao <zhuao at ustc dot edu>]

thanks you all for the valued information.

could you give me some link for the discussion?
some links for the experimental approach, and links for 'direct binding'.

I know little about linker, and would like to know more background.
thanks


发件人：Nicholas Miell <nmiell@gmail.com>
发送日期：2019-03-12 04:38:57
收件人：Florian Weimer <fweimer@redhat.com>,zhuao <zhuao@ustc.edu>
抄送人：libc-alpha <libc-alpha@sourceware.org>
主题：Re: is there plan to support 'linker namespace' in glib?>On 3/11/19 5:50 AM, Florian Weimer wrote:
>> * zhuao:
>> 
>>> I notice that android bionic support 'linker namespace': https://source.android.com/devices/architecture/vndk/linker-namespace
>>> it provides additional isolation among software components.
>>> it may also benefit some usage: 
>>>  - isolation prebuilt binaries with different toolchain (versioned glibc)
>>>  - it may also give us opportunity to use android binary (HAL) with glibc, by isolating glib and bionic world in different namespace
>>>
>>>
>>> do you think the above approach is possible?
>>>  if yes, is it possible to add such feature to glibc?
>> 
>> There have been many discussions over the year.  The requirements are
>> quite diverse: some people want group support as in the Solaris linker.
>> Others want dlmopen with a shared malloc (and perhaps shared other
>> libraries; our implementation currently shares only the dynamic linker
>> and nothing else).  Again others want to load the same library multiple
>> times, disregarding its soname.  Then there is a desire to have some
>> sort of firewall between different linker namespaces, as a general
>> framework, so that you can load the same soname multiple times, and
>> still achieving consistent execution.
>> 
>> I think that anything that is fairly general and actually works is still
>> a major research effort, in addition to the work that would be needed to
>> implement it in the current dynamic linker.  While a lot of research has
>> been done on modules and how to compose them in the 80s, a lot of that
>> knowledge seems to have been lost or is simply not available to people
>> working on C/C++ implementations today.
>> 
>> Thanks,
>> Florian
>> 
>
>And some people would like direct binding, especially because this is
>how Windows and Mac OS already work.