Сценарий:
- Мы хотели бы построить наши источники с помощью внешнего / hermeti c набора инструментов, чтобы все входящие в него компоненты, библиотеки и инструменты хоста игнорировались
- Для этого в Bazel-Configuration введен новый набор инструментов. >>> работает хорошо
- При использовании
-Wl,-rpath=$ORIGIN/%{runtime_library_search_directories}/... определяется относительный путь от бинарника к библиотекам, который должен быть загружен во время выполнения >>> Работает довольно хорошо - При выполнении
bazel run Двоичный файл выполняется, но используется LD хоста - Чтобы избавиться от этого, оболочка (записанная в Bash) вводится с помощью
--run_under. >>> грязный обходной путь
Проблема:
--run_under можно использовать только один раз. Нам также нужна эта опция для выполнения тестов в определенной среде c, и поэтому эта опция для нас не является предпочтительной. ИМХО, это тоже немного грязный обходной путь.
Мы также пытались использовать -Wl,--dynamic-linker=<<PATH_TO_LD>>. Но мы не смогли получить ни относительный, ни абсолютный путь к LD при связывании исполняемого файла.
Вопросы:
Есть ли ...
- ... есть ли способ получить абсолютный / относительный путь к LD при компоновке?
- ... есть ли другой способ запуска двоичного файла на хосте с помощью цепочки инструментов?
- ... возможность делать песочницу / ch root, чтобы автоматически использовать правильный LD цепочки инструментов?
Sidenotes:
- Используется Bazel 1.1.0
- набор инструментов - сборка GCC8 из источников
- хост - образ Ubuntu 18.04.1, работающий в docker