Подтвердить что ты не робот

Как получить RPATH с $ORIGIN для работы над Code:: Blocks GCC?

Я пытаюсь связать RPATH, содержащий специальную строку $ORIGIN, в исполняемый файл, созданный с использованием GCC с помощью Code:: Blocks IDE. Я указал

-Wl,-R$ORIGIN

в параметрах компоновщика для проекта, но вывод командной строки в GCC неверен (снят для ясности):

g++ -Wl,-R

Каков правильный способ указать этот аргумент для Code:: Blocks?

4b9b3361

Ответ 1

Тот, кто решил сделать маркер $ORIGIN, является злым ублюдком, который заслуживает особого места в программистском аду. Поскольку "$" является специальным символом для bash и других языков сценариев, таких как make, он закручивает все до тех пор, пока не будет тщательно экранирован. Хуже того, в зависимости от того, какую среду сборки вы используете, скорее всего будет изменяться спецификация того, как сбежать из системы.

В bash вам нужно придерживаться обратной косой черты перед $:

-Wl,-R\$ORIGIN

Code:: Блоки, по-видимому, также рассматривают $как специальные. Затем любой контроллер подпроцесса Code:: Blocks отправляет команду для обработки обратной косой черты как специальной. Таким образом, как обратная косая черта, так и значение $должны быть удвоены, чтобы сбежать должным образом. Поэтому в настройках компоновщика Code:: Blocks вам необходимо указать:

-Wl,-R\\$$ORIGIN

... который выдает:

-Wl,-R\\$ORIGIN

... в журнал сборки, но оболочка фактически отправляется:

-Wl,-R\$ORIGIN

... который, как указано выше, дает желаемый результат.

Какая боль.

Ответ 2

В дополнение к kblucks ответ, который обращается к вопросу для Code: Blocks.... Для таких, как я, кто наткнулся на эту страницу, ища, как это сделать с Make. Фокус в том, чтобы использовать дополнительный знак $в качестве escape-символа и заключить его в кавычки:

-Wl,-R,'$$ORIGIN/../lib'

Полное объяснение можно получить здесь: Использование ORIGIN для пути поиска динамической среды выполнения

Ответ 3

Если ваш исполняемый файл создается огромной сложной средой script, не созданной вами, и вы не хотите вникать в это, пытаясь работать с setenv LD_RUN_PATH='$ORIGIN/../lib'; если это не сработает, прагматичный подход заключается в создании обертки для ld:

#!/bin/sh
exec /usr/bin/ld -R '$ORIGIN/../lib' "[email protected]"

... затем выполните сборку с этим заглушкой на пути. На практике его можно вызвать для создания файлов .so или других исполняемых файлов, поэтому вам может потребоваться сделать это более сложным script, который решает, следует ли вставить RPATH. ИЛИ, запустите сборку без этого, и с помощью, и с помощью вишни.

(здесь "/usr/bin/ld" - это ld, который, как правило, запускался, что может быть где-то еще. gcc не может забрать ld из пути, см. переменные среды gcc, чтобы переопределить это. Единственное использование. Не гарантируется быть менее ужасным, чем любой другой подход).