shared libraries

Ты сам то понял что сказал? И где ты видел адресное пространство либы? А? С какими объектами ОС связаны адресные просранства?

ну а если мне нужно создать объект (один) и чтобы он использовался либой при вызове какой нибуть либной функции? мне что его создавть в кажном процессе?

Адресное пространство есть у процесса. Не важно использует программа библиотеки или нет, адресное пространство будет всегда одно. То есть ты можешь создать объект в библиотеке, передать его адрес в основную программу и все будет работать.

p.s. А почему бы тебе не написать программку с библиотекой из пары строк и не проверить все на практике?

Разделяемые библиотеки - это понятие говорящее о том,
что код этих библиотек может быть использован одновременно
в разных процессах. процесс загружает в свое адресное пространство
код библиотеки и с ним работает. В это время другой процесс
может делать то-же с той-же библиотекой. Это используется при
динамической загрузки библиотек во время выполнения.
Общаться процессы могут только посредствам средств межпроцессорного
взаимодействия. Библиотека тут ни при чем.
Оператор 'new' выделяет память в "куче" памяти процесса: 4Gb 
 - в Linux за вычетом памяти на стек и под глобальные переменные.
Такой памятью обладают все процессы. Библиотека памятью не обладает,
она обладает размером. Разделяемые библиотеки используются для 
 экономии места на диске, если они используются многими программами. 

А если какаято переменная в експортируемой ф-и будет обьявлена как static она будет общей на все процессы или каждый процесс получит её копию???

>А если какаято переменная в експортируемой ф-и будет обьявлена как static она будет общей на все процессы или каждый процесс получит её копию???

не будет она общая. У каждого процесса свой экземпляр.

static - это идентификатор области видимости в программе.
(прошу извинить забыл как это называется научно)
Когда программа запуcкается,  ОС создает контекст процесса
в котором выполняется код программы.
  Адресное пространство процесса является частной собственностью
процесса. Если сам процесс сделает некие переменные видимыми
для других процессов, то их будет видеть другие процессы.
Иначе нет.
  Переменная объявленная как  static будет общей для той
области видимости где она объявлена и к которой есть доступ.
И она не будет обнуляться при выходе из этой области видимости.
static - пременные не на стеке (автоматические переменные).

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

Нет никакой разницы где реализован код в библиотеке или
в функции main(). Засасывая библиотеку в адресное пространство
процесса происходит копирование. 
 Библитотеки - для экономии места на диске в случае использования
их в других программах и для модульности и удобста подмены в
некоторых случаях.
 Смотрите литературу по С/С++ на предмет: static,
 IPC - средства межпроц. взаимодействия, 
литературу о работе библиотек - многое есть в Intenete, точно,
 может конечно не в полном объеме, но достаточно для общего представления.

а как Вы прокоментируете это? :

The shared library's read-only segment (in particular, its .text section) can be shared among all processes; while its write-able sections (such as .data and .bss) can be allocated uniquely for each executing process. This write-able segment is also referred to as the object's Static Data Segment. It is this static data segment that creates most of the complexity for the implementation of shared libraries.

мля!


The shared library's read-only segment (in particular, its .text section) can be shared among all processes; while its write-able sections (such as .data and .bss) can be allocated uniquely for each executing process. This write-able segment is also referred to as the object's Static Data Segment. It is this static data segment that creates most of the complexity for the implementation of shared libraries.

> Засасывая библиотеку в адресное пространство
>  процесса происходит копирование.

копирования не происходит.

> Библитотеки - для экономии места на диске

и памяти.

библиотека грузится с помощью mmap(MAP_PRIVATE).
не readonly данные еще с PROT_WRITE.

если в библиотеке имеем int x, эта переменная
после загрузки одна на все процессы, которые
ее используют. после того, как процесс в эту
переменную пишет, процессу будет создана ее
private копия (будет pagefault, целая сттраница
с этой переменной будет дублированна). неважно
была ли эта переменная static или нет, это имеет
смысл толко для компилятора.

если она была обьявлена как const, линкер может
разместить ее в readonly сегменте, и мы получим
SEGFAULT.

разумеется, я имел в виду не переменную в стеке :)

копирование кода _может_ иметь место, если код
компилировался без -fpic.

все сказанное, разумеется, сильное упрощение.

в библиотеке есть 2 сегмента: данных, кода.
Код: "read-only" - общий на все процессы. 
Данные: "read-write", копируются в контекст процесса 
  - становятся личными.
Все грубо. Может кто и уточнит.

ну ведь только что писал...

> Код: "read-only" - общий на все процессы.

да. но если он был компилирован без -fpic, там
будут необходимы relocations. при загрузке они
будут разрешаться, что приведет к записи в код,
что приведет к копированию страницы ядром после
pagefault, т.к. MAP_ANONYMOUS. все это происходит
прозрачно для приложения. само копирование, в
свою очередь, прозрачно для dynamic linker, который
загружает библиотеку и делает эти fixups.

> Данные: "read-write", копируются в контекст процесса

не копирутся! mmap, опять же. см предыдущий мой пост.

Короче, как реализовано - не суть важно память как уже сказано выделяется процессу, а для межпроцессного взаимодействия надо использовать IPC. Пиши как если бы не было разделяемых библиотек. Только порядок инициализации модулей (.o) нельзя использовать (см info gcc). Но вот если либа грузится явно с помощью dlopen то new лучше не использовать - см. C++ dlopen HOWTO.

ЗЫ: программу отлаживать проще без разделяемых либ. Кажется в руководстве по autoconf/automake был пример как для отладки прогу компилить со статически, а для релиза - с разделяемыми либами.

Для idle:  Да я согласен со всем что Вы пишите.
 Но парень упорный, не понимает он и не хочет читать.
Я ему уже писал правда в общих чертах и сказал что почитать и что поискать.
Кстати есть библиотеки разделяемые с загрузкой явно (dlopen()), 
а есть линкованные. 
Кстати Вы пишите: 
>> Данные: "read-write", копируются в контекст процесса
>не копирутся! mmap, опять же. см предыдущий мой пост.

Ну хорошо, тогда как назвать то что у каждого процесса свои данные ?
Копируется начальное состояние это правильнее ?

#man mmap
MMAP(2)             Linux Programmer's Manual             MMAP(2)
NAME
       mmap, munmap - map or unmap files or devices into memory
...

Как правильнее перевести 'map or unmap files or devices into memory'?
Карта, отображение файлов устройств в памяти ?  Но ведь копия того что есть
или не так ?
Возможно, согласен термин копия - не удачен.

Хотя вот ваши слова:
"...после того, как процесс в эту переменную пишет, 
процессу будет создана ее private копия 
(будет pagefault, целая сттраница
с этой переменной будет дублированна).
...."

Ну хорошо это точнее, при загрузки не копируется, копирование происходит позже,
 но ведь копия или Вы отрекаетесь от своих слов.
Хотя спасибо что поправили.

> Кстати есть библиотеки разделяемые с загрузкой явно (dlopen()), 
> а есть линкованные. 

без разницы. "линкованые" тоже будут подгруженны с помощью
dlopen() (фактически), только сделает это dynamic linker.

по поводу копирования. все это похоже на fork(). если есть
какая-то переменная (область памяти, на самом деле), то после
форка она физически одна для обоих процессов. как только
любой из них в нее пишет, ему создается private копия.

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

> по поводу копирования. все это похоже на fork(). если есть > какая-то переменная (область памяти, на самом деле), то после > форка она физически одна для обоих процессов. как только > любой из них в нее пишет, ему создается private копия. Ну так и механизм один и тот же используется - страница помечается как read-only, и при попытке записи возникает pagefault.

> Ну так и механизм один и тот же используется - страница помечается как > read-only, и при попытке записи возникает pagefault.

ну так а я о чем?

спасибо за столь интересную дискусию. я правда не все понял :)
только ответьте пожалуйста на вопрос да или нет :)


в либе:

static Class::m_pixmap = 0L;

void Class::init()
{
    // вызывается один раз при загрузке либы
    m_pixmap = new QPixmap("porno.png"); // :)
}

QPixmap * Class::getPixmap()
{
     return m_pixmap;
}

теперь внимание вопрос :)
процессы вызвавшие getPixmap() получат указатель на один и тот же объект?
ну вы поняли что я хочу сделать? :)

нет, на разные.