Re[2]: проблема с ликовкой (Solaris, gcc)
От: anagaf  
Дата: 25.08.09 17:02
Оценка:
Здравствуйте, zaufi, Вы писали:

А>>Есть некая библиотека, скажем libacb.so. При сборке, как обычно, создается файл и три ссылки:

А>>libabc.so.1.0.0
А>>libabc.so.1.0 -> libabc.so.1.0.0
А>>libabc.so.1 -> libabc.so.1.0.0
А>>libabc.so -> libabc.so.1.0.0

А>>Есть программа, использующая libso.so, в make-файле прописано -labc. Проблема в том, что в результате исполняемый файл зависит не от libabc.so, а почему-то от libabs.so.1

Z>ммм... не понял в чем проблема то? тебе не фиолетово кто там с кем линкуется -- главное чтобы работало правильно...

Работает неправильно. Я наврал (Аноним — это был я, если что), с abc линкуется не конечное приложение, я другая библитека — xyz, которая, в свою очередь, динамически загружается конечным приложением app.Используется Qt и xyz загружается при помощи QLibrary::load():

load failed: "QLibrary::load_sys: Cannot load libxyz.so (ld.so.1: app: fatal: libabc.so.1: open failed: No such file or directory)"

То есть, как я понимаю, он хочет именно libabc.so.1 и имеющийся libabc.so его не устроит.

Z>если не соблюдать library versioning system то можно больно огрести при попытке установить две(несколько) версии libabc и несколько приложений работающих с разными libabc...


По какой-то причине используется нестандартный подход: библиотеки не копируются в /usr/local/lib или еще куда, а хранятся в директории программы. И из всех вариантов libabc там присутствует только libabc.so

А>>Как это можно побороть?

Z>а чем это мешает сейчас?

См.выше. Кроме того, хочется понять, что происходит. Почему создается зависимость именно на .so.1, а не на .so.1.0.0 или на просто .so.

Что интересно, под Линуксом все проходит нормально
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.