Напомните соременые соглашения как держать в системе одновременно две версии библиотеки и переключатся между ними?

Специализация по версиям, больше наверно никак. Насчет конфигурации сборки - по хорошему, она должна быть приписана каким-то образом к версии(

libsome.so.x.y.z

libsome.so.x.y.z-d

libsome.so это обычно симлинк на libsome.so.1.2.3 или libsome.so.1.2.4 в системе, меняй симлинк и всё, а приложение должно требовать libsome.so, при этом в самой библиотеке должен быть захардкожен номер версии библиотеки что бы приложение проверяло нужное ли ей суют или нет.

В приличных домах это делают через симлинки. Например, в /usr/lib может лежать, скажем, libGL.so, указывающий на mesa/libGL.so или nvidia/libGL.so

На скорую руку можно держать директорию с дебажными библиотеками в ./debug, релизные библиотеки оставить в системных директориях. Тогда дебажный запуск сведется к LD_LIBRARY_PATH=./debug:$LD_LIBRARY_PATH ./binary

Смотря для чего, рекомендую глянуть Nix

Сомневаюсь, что есть общепринятые соглашения. Если речь о Debian и пакетах - https://wiki.debian.org/DebianAlternatives (в Redhat тоже есть аналог); если чисто для себя - костылить симлинки.

К библиотекам обычно такое не применяют.

Обычно с библиотеками не делают и того, что ты хочешь сделать. alternatives, по крайней мере, стандартный системный способ, решающий приведенную задачу.

Я как-то делал

  if (debug_mode == 0) {
    p_lib_handle = dlopen ("./libtest_release.so", RTLD_LAZY);
  }
  else {
    p_lib_handle = dlopen ("./libtest_debug.so", RTLD_LAZY);
  }

libsome.so — это симлинк на конкретную версию для того, чтобы компилятор при сборке принимал всегда ключ -lsome, а конкретная версия бралась из системы, что там установлено сейчас. В бинарник при этом вписывается soname библиотеки (например, libsome.so.1.2.3) и при загрузке будет искаться файл именно с таким именем. Симлинка libsome.so при этом в системе может попросту не быть. Некоторые библиотеки идут даже дальше: в soname вписывается libsome.so.1, а симлинк libsome.so.1 в системе может указывать как на libsome.so.1.2.3, так и на libsome.so.1.5.6, если версии 1.2.3 и 1.5.6 бинарно совместимы.

Используй систему управления зависимостями. Например: https://www.conan.io/

Фундаментально эта проблема решена в Nix.

Брать пути к библиотекам из переменных окружения. Для тестов инклудишь одно, для релиза - другое.

Фундаментально nix нормально не решает проблему запуска одного и того же бинарника с разными библиотеками.

Не надо так делать.

Почему? Как надо?

Напомните соременые соглашения как держать в системе одновременно две версии библиотеки и переключатся между ними?

установить и использовать gentoo.

использовать gentoo.

это же несовременно и даже ретроградство

Для отладки есть LD_PRELOAD, он прекрасно работает с Nix.

Для продакшона все зависимости должны быть строго фиксированными (как в Nix).

LD_PRELOAD - это переменная окружения.

Про продакшн у ТС и в моём ответе ничего не было. Было про проверку работоспособности одного и того же бинарника с разными библиотеками(девелоперской и релизной), насколько я понял.

LD_PRELOAD - это переменная окружения.

Это хорошо или плохо?

Хорошо. Но ты, видимо другой анонимус. Там выше какой-то твой собрат сказал, что использовать переменные окружения плохо для этой задачи.

Если тебе нужно чисто для проверки и отладки - то LD_PRELOAD, как и советовали.

А зачем их держать в системе? Клади рядом со своей программой.

все сказали, и я скажу. Nix.

Хочешь квартиру покупай, супер скидки https://agrovid.com