Перемещение библиотек и заголовков - PullRequest
2 голосов
/ 14 января 2010

У меня есть некоторый код на c, который предоставляет libfoo.so и libfoo.a вместе с заголовочным файлом foo.h. Большое количество клиентов в настоящее время используют эти библиотеки из каталогов / old_location / lib и / old_location / include, где они находятся.

Теперь я хочу переместить этот код в / new_location. Однако я не могу информировать клиентов об этом изменении. Я бы хотел, чтобы старые клиенты продолжали получать доступ к библиотекам и заголовкам из /old_location.

Для этого будет работать создание символических ссылок на библиотеки / заголовки для новых локаций?

/old_location/lib/libfoo.so -> /new_location/lib/libnewfoo.so
/old_location/lib/libfoo.a  -> /new_location/lib/libnewfoo.a
/old_location/inlcude/foo.h -> /new_location/inlcude/foo.h

[Обратите внимание, что мне нужно назвать новую lib как lib new foo, а не libfoo из-за некоторых ограничений. Может ли это переименование вызвать проблемы? И все же код C, который их генерирует, не изменился.]

Кажется, это работает для нескольких простых случаев, которые я пробовал. Но могут ли быть случаи, когда клиенты используют библиотеки libs и headers таким образом, который может сломаться в результате этого изменения. Пожалуйста, дайте мне знать, какие сложности могут быть связаны с этим. Извините, если это кажется новичком, я с трудом раньше работал с c и являюсь Java-человеком.

Ответы [ 4 ]

2 голосов
/ 14 января 2010

Вы должны различать время компиляции и время выполнения .

Во время компиляции клиенты должны обновить свой Makefile и / или настроить логику.

Для времени выполнения вы просто сообщаете ld.so через ld.so.conf о том, где найти библиотеку .so (или говорите своим клиентам настроить LD_LIBRARY_PATH, второй лучший выбор). Статическая библиотека не имеет значения, поскольку ее код уже встроен в исполняемый файл.

И да, предоставляя символические ссылки, вы также можете сделать так, чтобы ход «исчез» и предоставлял все файлы через старое местоположение.

И все это довольно проверяемо с вашей стороны до развертывания.

1 голос
/ 14 января 2010

Единственная проблема с символическими ссылками может быть, если некоторые клиенты монтируют новое местоположение с другим путем, что возможно в сетевой среде типа Unix. Например, вы можете иметь местоположение как:

/var/stuff/new_location/include/...

и клиент может монтировать это как:

/auto/var/stuff/new_location/include/..

В этом случае относительная символическая ссылка может работать лучше, т. Е .:

old_location/include/foo.h -> ../new_location/include/foo.h

Еще одна вещь, которую следует рассмотреть, это заменить old_location / foo.h на:


/*
 * Please note that this library has moved to a new location...
 */
#include "new_location/include/foo.h"
1 голос
/ 14 января 2010

Я не вижу причин, по которым это может сломаться, это больше вопрос о символических ссылках, чем C. Для ничего не подозревающей пользовательской программы (в которой нет специального кода для обнаружения символических ссылок и жалоб), символическая ссылка прозрачна .

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

0 голосов
/ 14 января 2010

Символические ссылки будут работать в любой операционной системе и файловой системе, поддерживающей символические ссылки.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...