dlmopen and isolation of loaded libraries

dlmopen and isolation of loaded libraries

[Александр Ващилко]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

Hi, I am developing a project that has the functionality of loading
libraries of some third-party products which shipped with their own
versions of libstdc++ or glibc.
But my project needs to use its own versions of the same libraries.
I found the dlmopen function, but as I understand, it has limited isolation
functionality.

Also, as I understand from this article
https://sourceware.org/glibc/wiki/LinkerNamespaces, every new namespace
created by dlmopen have own copy of glibc of version from which dlmopen
was called.

I there any way to load third-party libraries with their own versions of
libstdc++, their own versions of glibc, or all their own libraries of their
own versions at the same time?

Anyway, even if dlmopen doesn't support the required functionality, do
glibc and libstdc++ support the simultaneous existence of different
versions of these libraries at the same time in the same process?
Maybe I will find a way to do what I need.

Thanks.

Re: dlmopen and isolation of loaded libraries

[Florian Weimer]

* Александр Ващилко via Libc-help:

> Anyway, even if dlmopen doesn't support the required functionality, do
> glibc and libstdc++ support the simultaneous existence of different
> versions of these libraries at the same time in the same process?

For glibc, there can only be one version, and it has to match the build
of ld.so.  Even with an identical libc.so.6 everywhere, there is some
loss of functionality (e.g., the secondary namespaces cannot create
threads).

For libstdc++, it may work depending on what you are doing and how
different the versions are.  Even with dlmopen, STB_GNU_UNIQUE symbols
lack full isolation.  Like the stdio streams, std::cout etc. will not
work reliably because the required global data is not shared across
instances.  It's also not possible in general to pass pointers from one
namespace to the other even if the types are the same.

Thanks,
Florian

Re: dlmopen and isolation of loaded libraries

[Basile Starynkevitch]

[-- Attachment #1: Type: text/plain, Size: 2105 bytes --]


On 27/02/2023 12:48, Александр Ващилко via Libc-help wrote:
> Hi, I am developing a project that has the functionality of loading
> libraries of some third-party products which shipped with their own
> versions of libstdc++ or glibc.
> But my project needs to use its own versions of the same libraries.
> I found the dlmopen function, but as I understand, it has limited isolation
> functionality.


Yes. I assume your project runs a single process under Linux. Its 
virtual address space is not "isolating" shared libraries.

For debugging, try adding a routine reading /proc/self/maps (a textual 
file). Maybe also use pmap(1) 
<https://man7.org/linux/man-pages/man1/pmap.1.html> command.


Better isolation requires a multi-process approach. See also /proc and 
https://man7.org/linux/man-pages/man5/proc.5.html

>
> Also, as I understand from this article
> https://sourceware.org/glibc/wiki/LinkerNamespaces, every new namespace
> created by dlmopen have own copy of glibc of version from which dlmopen
> was called.
>
> I there any way to load third-party libraries with their own versions of
> libstdc++, their own versions of glibc, or all their own libraries of their
> own versions at the same time?
>
> Anyway, even if dlmopen doesn't support the required functionality, do
> glibc and libstdc++ support the simultaneous existence of different
> versions of these libraries at the same time in the same process?


This probably won't work well, or is a very brittle approach (conflict 
for similar global data mmap-ed twice?)


For details, read Levine's book: /Linkers & Loaders/, and download and 
study the source code of GNU libc and of musl-libc 
<https://musl.libc.org/> (and its documentation).


BTW, my pet open source project is the /RefPerSys/ open source 
artificial intelligence engine on http://refpersys.org/ (some source 
code on https://github.com/RefPerSys/RefPerSys ...)

Regards

-- 
Basile Starynkevitch<basile@starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/