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

а пример можно?

Не обязательно! 
Через IPC - проверено и надёжно.
Напрямую - деревянный велосипед на треугольных колёсах.

Это моё убеждение. Я не призываю Вас следовать ему... -)

Добавлено через 7 минут и 20 секунд


Весьма абстрактный ответ...
Так как Вы не ответили на третий мой пункт:

то у меня возникло подозрение, что Вы просто забыли задать линкеру ключик -l (или -L)
задающий эти самые so-шки. 

Я ошибаюсь ?

проверено, надежно, но для другой задачи. 

IPC подразумевает, копирование в ядро, затем передачу (копирование обратно в юзерсейс), потом снова копирование уже в требуемую структуру. При этом занимаются ресурсы ядра

для этой задачи это все не нужно, структура на расстоянии вытянутой руки, просто возьми, да положи




мне не совсем понятен вопрос, -l там не требуется, так как линковки с данными so-шками нет (линк происходит динамически). Модули прекрасно собираются, и работают



Это сообщение отредактировал(а) fish9370 - 11.11.2014, 16:53

Линковка двух взаимодействующих модулей происходит ВСЕГДА.  Иначе они не смогут взаимодействовать. 
Но эта линковка может быть двух типов:

• Статическая, когда все взаимодействующие модули собираются в одну кучу и все линки настраиваются заранее.
• Динамическая, когда в исполняемом модуле остаются неразрешённые ссылки, которые настраиваются по мере необходимости.

Во втором случае программа, настраивающая неразрешённые ссылки (Динамический линкер) должна знать, ГДЕ искать эти самые точки, на которые нужно настроить неразрешённые ссылки. so-шки линкуются динаически. Поэтому, линкер должен знать, в какой so-шке какие точки входа наличествуют.

Поэтому, динамический компоновщик Linux ведёт хэш точек входа во все известные ему so-шки. Что бы такой хэш можно было обновлять, установлено соглашение, что все so-шки располагаются в

• /lib
• /usr/lib
• /usr/local/lib

Команда



заставляет линкер перестроить его хэш.

Если so-шка расположена НЕ в стандартном месте, то её расположение должно быть задано явно, с помощью ключей -l или
-L.

Не совсем так. Для задания нестандартного места для so в run-time используется ключ -rpath (или переменная окружения LD_LIBRARY_PATH). А ключи -i и -L используются на этапе линковки, что бы линкер вообще был в курсе, что при запуске программы нужно загружать данные so'ки, ну и что в них надо искать неразрешенные до сих пор имена.


Как раз нужно, что бы загружаемый модуль знал, где искать extern struct hashtable users;

нет, Вы слишком категоричны. В моей практике, чаще всего так: имеется глобальный объект, допустим двунаправленный связанный список, который объявлен в ядре (ядре программы). Ядро грузит модуль (some-module.so) с помощью dlopen. Модуль при инициализации добавляет обработчики к этому глобальному списку. Последующие модули делают тоже самое. При этом непосредственно между собой модули не линкуются. А при необходимости выполнить код другого модуля, они обращаются к этому списку. В момент выгрузки, они удаляют свои обработчики из этого списка и на том их взаимодействие заканчивается.

Вы понимаете, что это совсем другая практика, нежели та, что указываете Вы?

пожалуйста, освежите знания man 3 dlopen





как раз нужен ключ -l? -l я не использую, поймите же наконец



Это сообщение отредактировал(а) fish9370 - 12.11.2014, 11:47

Изначальная задача сформулирована не очень однозначно- все-таки на каком этапе необходимо получить связаывание объектов переменных- на раннем этапе при сборке исполняемого модуля, или же на позднем при осуществлении вызовов dl*()
Если речь идет о первом случае, то очевидно что Вы сразу должны указать целевую область связывания, объявить для нее локальный идентификатор псевдонима, а при запуске выставить корректный LD_LIBRARY_PATH
Если речь о втором случае, о каком именном псевдониме для связывания вообще можно говорить?! Подключили в процессе исполнения, забрали необходимый объект, сделали ссылку с учетом структуры - или же включили соответствующий .h-файл

Ах да и чтобы не пришлось лишний раз проводить незабываемые минуты веселья с demangler'ом, сделайте в исходном модуле такую штукенцию

да, Вы правильно меня поняли



вариант хороший, но так хотелось обойтись без этого

дело в том, что я не пользуюсь этой функцией, я отдал это на откуп самому модулю, который сам регистрирует общие объекты

а тут я вообще хотел на халяву, как-то автоматом связать

Это мы поняли, и поэтому у вас и происходит это -



И что бы этого не происходило, и надо подать в сборку модулей -l<router> (где librouter.so и содержит ваш struct hashtable users). Физически struct hashtable users останется там же, где и был (в  librouter.so), а в модулях появится только ссылка на него (в виде имени библиотеки) и связывание с его экспортируемыми символами.

я вас понял, спасибо, возможно это поможет