Как сделать $ ORIGIN в RPATH не следовать символическим ссылкам?

У меня есть исполняемое app , которое зависит от библиотеки libbar.so и загружает ее через RPATH с помощью $ORIGIN следующим образом:

 $ readelf -d app Dynamic section at offset 0xe08 contains 26 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libbar.so] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/lib/] 

Было бы неплохо запустить его в соответствующей структуре каталогов, сделанной с символическими libbar.so на исполняемый файл и libbar.so :

 $ ls -R .: app@ lib/ ./lib: libbar.so@ 

– но компоновщик следует символическим ссылкам к исходному файлу исполняемого файла, устанавливает $ORIGIN в каталог исполняемого файла и решает пути зависимостей оттуда. Можно ли это сделать не так? Таким образом, путь к каталогам, в поисках файлов lib, символические ссылки рассматриваются как реальные файлы файловой системы («конечные точки» поиска).

Кроме того, некоторые соображения по этой проблеме:

  1. Удобно иметь двоичные файлы, созданные для поиска зависимостей в нескольких реляционных каталогах , например, в $ORIGIN/ самого двоичного $ORIGIN/appname_dependencies/ а также в $ORIGIN/appname_dependencies/ (так что можно просто скопировать двоичные и его «зависимости» в один каталог и запустить его, но также имеет откат для более сложной настройки с несколькими версиями одного и того же двоичного кода в системе).

  2. Из-за требования нескольких путей поиска зависимостей, RPATH – это метод поиска : «сокращенное» имя зависимости ( NEEDED Shared library: [./libbar.so] ) устанавливает только один путь поиска. Кроме того, для простоты пути разрешения зависимостей должны быть в самом двоичном формате.

  3. Приятно иметь возможность комбинировать все двоичные файлы (приложение и все его «зависимости») в полном графике зависимостей со ссылками , а не копировать файлы. И символические ссылки более устойчивы, чем жесткие ссылки: они связаны между файловыми системами. Фактически, у меня есть эта проблема в одной академической среде кластера Linux, где жесткая ссылка на родительский каталог не может быть выполнена:

      $ ln ../afile ln: creating hard link `./afile' => `../afile': Invalid cross-device link 

Если вы действительно хотите использовать символические ссылки, вы можете создать такую ​​конфигурацию:

  • переместите исполняемый файл в свой собственный каталог
  • сделать символическую ссылку из «нормального» местоположения на перемещенный исполняемый файл
  • создавать символические ссылки в каталоге исполняемого файла для разделяемых библиотек, которые вы хотите разрешить