Ivan IgnatovКомпилятор выдаёт один объектный файл на каждую единицу трансляции - .cpp файл с кучей включенных .h. В этот объектный файл попадает таблица экспорта - набор "символов" (строк/имён) с атрибутами и адресом для каждого символа. Имена функций, глобальных переменных и т.п.Да
Ivan IgnatovАдрес - всмысле по какому смещению от адресного пространства процесса или какой-то секции (напр. секции кода, секции данных) данный символ будет лежать в памяти. Нет. Адреса это дело линкера. В объектнике только локальные адреса: "Здесь лежит код этой функции, а здесь этой". А где они будут лежать в реальности в адресном пространстве решает линкер.

Ivan IgnatovКогда из набора объектных файлов линкуется один .so/.dll/.a/.exe, наши таблицы экспорта из всех объектных файлов тупо сливаются в одну. Если какой-то символ где-то дублируется, линкер матерится (как оно под разными платформами)?Да. От платформы не зависит.

Ivan IgnatovЕсть ли в таблице экспорта какая-то "разная степень видимости"? Т.е. могут там лежать символы public, private или ещё что-то такое хитрое? Незнаю для чего! Есть ли там что-то такое или всё попавшее в таблицу экспорта видимо извне линкером?Да, есть.

Ivan IgnatovСколько в каждом .obj / .so / .dll - файле таблиц экспорта? Одна на весь файл или у неё существуют разные разделы?эээ... ты про какой из форматов спрашиваешь? В принципе все они представляют из себя библиотеки неких объектов. Соответственно таблицу экспорта обычно многосекционные.
И не забывай что существует несколько разных форматов obj, несколько разных .so, несколько разных .dll...

Ivan IgnatovC++ - классы выступают как пространства имён для "символов". Плюс сами namespace-ы. Для них есть какие-то правила формирования имён символов или каждый компилятор заворачивает двойные двоеточия ("::") как-то по-своему?Есть такая вещь "name mangling" называется. Очень веселая штука.

Ivan IgnatovЧто сделать в C/C++ - программе, чтобы обеспечить символу присутствие в таблице экспорта?По разному. Зависит от языка (С или С++) и компилятора. Начни с ответа на вопрос: а где и зачем тебе это нужно?

Ivan IgnatovПравильно я понимаю, что static глобальные переменные не попадут в таблицу экспорта, обеспечивая локальность символа для данной единицы трансляции? А если надо заюзать глобальную переменную из другой единицы трансляции, то нужно объявить эту переменную со словом extern?Для глобальных переменных, на этапе компиляции - да.

Ivan IgnatovПлюс интересно почитать что-нибудь касающееся сабжа, но что у меня не упомянуто и особо интересно почитать о различиях линковальной кухни под разными платформами, о платформенно-зависимых ключевых словах языков C/C++ под разными платформами: о виндовых "__declspec(dllexport)" и прочей такой тряхомути.я не знаю где бы это описывалось в одном месте. Ну можно начать с теории компиляторов. Например вот: http://www.amazon.com/Compilers-Principles-Techniques-Edition-ebook/dp/B004P5NQYI/ref=dp_kinw_strp_1

Ivan IgnatovЧто такое hidden visibility в gcc? Ладно, погуглю... )Традиционно, на gcc/linux все объекты видимые из других единиц трансляции также становятся видимыми и когда все это собрано в разделяемую библиотеку. На винде наоборот - хочешь чтобы объект был видим из библиотеки - объяви его специально. В последних gcc добавили специальный аттрибут командующий линкеру спрятать объект (функции/классы/переменные) и не показывать его в библиотеке.