Соединение приложения к libbz2.so.1, а не libbz2.so.1.0
Проблема с блоками попытки/выгоды, которые ловят все исключения, состоит в том, что Ваша программа находится теперь в неопределенном состоянии, если неизвестное исключение происходит. Это идет полностью против сбоя, быстро управляют - Вы не хотите, чтобы Ваша программа продолжилась, если исключение происходит. Вышеупомянутая попытка/выгода даже поймала бы OutOfMemoryExceptions, но это - определенно состояние, в котором не будет работать Ваша программа.
блоки Попытки/наконец позволяют, Вы для выполнения очищаете код при тихом сбое быстро. Для большинства обстоятельств Вы только хотите поймать все исключения на глобальном уровне, так, чтобы можно было зарегистрировать их, и затем выходить.
2 ответа
Почему бы вам вместо этого просто не связать статически?
Я делал это в прошлом для сборок на Ubuntu и развертывания на RHEL, который отлично работает со статическими сборками.
Вот небольшая предыстория, чтобы объяснить, что было связано. На платформах ELF переданные вами флаги -L и -l определяют местонахождение двоичного файла только во время компоновки. Если компоновщик определяет, что библиотека требуется, он создает ссылку на SONAME в этом двоичном файле, независимо от того, как он был вызван. Например:
$ objdump -p /lib64/libbz2.so.1 | grep SONAME SONAME libbz2.so.1
Итак, независимо от того, как называется libbz2, именно это будет отображаться как зависимость. Опять же, например, выполнение чего-то полностью взломанного:
$ ln -s /lib64/libbz2.so.1 libblah.so $ g++ t.C -L. -l blah
У вас есть видимость связи с libblah, но поскольку значение имеет SONAME в этом двоичном файле, ваша зависимость по-прежнему остается libbz2.so.1
$ ldd a.out | grep bz2
libbz2.so.1 => /lib64/libbz2.so.1 (0x00002b3d1a000000)
Кроме -static обман (который может кое-что сломать), из этой неразберихи нет простого выхода (в идеале библиотека могла бы хорошо управлять версиями символов, как glibc, и никогда или редко меняла бы свое SONAME).