.so и классы

>просто ведь в .so только функции лежат (или нет?)?

Нет. Можно создать .so, потом прилинковать статически или динамически, а в исходнике, в котором хочешь сказать new, делаешь инлкюд декларации класса. то есть реализация может быть как в .o, так и в .so. Без разницы

а ещё в .so может быть функции _init, которая выполнится до того, как dlopen вернёт управление

спасибо.

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

Есть пуленепробиваемый вариант. Код, который необходимо выделить в SO, отрезается от всего остального с помощью чистых абстрактных интерфейсов (причем в интерфейсах стоит использовать только простые типы, без STL). Из SO экспортируются только фабрики, возвращающие указатели на экземпляры объектов, реализующих эти интерфейсы. Фабрики объявляются как __attribute__((visibility("default"))) extern "C". Опционально, для уж полного сокрытия реализации, все остальное в so-шке компилируется с флагом -fvisibility=hidden (только будтье осторожны, после такого флага для объектов, которые будут жить в so-шке, в клиентском коде перестанет работать RTTI и, соответственно, не будут ловиться исключения, бросаемые из SO наружу).

При условии неизменности интерфейсов, эта схема будет работать даже а) если изменится схема mangling-а имен, б) если изменится внутреннее содержание классов-реализаций.