Ваш комментарий полностью меняет ваш вопрос:
Я не ожидаю, что они смогут общаться друг с другом через интерфейс C ++, а только через интерфейс C. Я ожидаю, что можно будет загружать библиотеки SharedLibraries от разных поставщиков в один процесс, и они не будут мешать друг другу. (Этот, кстати, работает над Windows десятилетиями)
Этот элемент поведения в значительной степени независим от системы. Windows PE формат и Linux ELF достаточно похожи по дизайну, поэтому они не добавляют никаких дополнительных ограничений или возможностей для этого topi c. Так что, если ваша техника будет работать в Windows, то она должна работать и в Linux, просто заменив .dll файлы на .so файлы.
Linux имеет большую стандартизацию около соглашения о вызовах , чем Windows, так что если что, вы обнаружите, что Linux делает это проще.
Исходный ответ
Вопрос:
есть только одно пространство имен для символов в процессе Linux?
Верно; в загрузчике Linux нет такой вещи, как пространства имен.
Как вы, возможно, знаете, C и C ++ - очень разные языки. В C ++ есть пространства имен C нет. Когда загружаются библиотеки (как в Linux, Unix, так и в Windows), понятие пространства имен отсутствует.
Компиляторы C ++ используют изменение имени , чтобы гарантировать, что имена изолированы пространства имен в вашем коде не компилируются при размещении в качестве символов в общем объекте. C компиляторы этого не делают и не должны этого делать, потому что нет пространств имен.
Вопрос:
Символы обнаруживаются и разрешаются только по имени символа. Источник символа является случайным при наличии неизвестного исполняемого файла (предоставляется заказчиком) или совместно используемых библиотек, предоставляемых заказчиком.
Давайте заменим слово «случайный» на непредсказуемый. Это тоже правильно. Из Википедии :
Язык C ++ не определяет стандартную схему оформления, поэтому каждый компилятор использует свою собственную. C ++ также имеет сложные языковые функции, такие как классы, шаблоны, пространства имен и перегрузка операторов, которые изменяют значение определенных c символов в зависимости от контекста или использования. Мета-данные об этих функциях могут быть устранены путем изменения (украшения) имени символа. Поскольку системы изменения имен для таких функций не стандартизированы для разных компиляторов, немногие компоновщики могут связывать объектный код, созданный разными компиляторами.
Вопрос:
Какова история с процессом на LINUX, который dlopen () несколько разделяемых библиотек и исполняемый файл и / или разделяемые библиотеки, скомпилированные с помощью разных компиляторов C ++ (например, предоставляется клиентами или третьими сторонами).
Конечно, dlopen () общий объект, но dlsym () будет сложно использовать, потому что искажения имени. Вам придется вручную проверить общий объект, чтобы определить точное имя символа.
Каковы последствия использования нескольких копий (разных) libc ++ внутри одного процесса (некоторые из них имеют c)?
Если вы зашли так далеко, тогда я В первую очередь я бы позаботился об управлении памятью. libc ++ отвечает за реализацию new и delete и преобразование их в запросы памяти из ОС. Если они будут вести себя как GNU mallo c () и free () , они могут управлять своим собственным пулом памяти. Было бы трудно предсказать, что произойдет, если вы вызовете delete для объекта, созданного другой libc ++.