Есть кроссплатформенная библиотека, которая собирается практически без переделок на любой платформе. И вот решил я интереса ради собрать её под Unix. Поставил на виртуальную машину типа VMWare юбунту, и скачал codeblocks для сборки. Создал в нем проект типа Shared Library и разместил в нем все файлы. Также я добавил в настройки проекта и def-файл, который у меня используется на всех других платформах.
Проект компилируется, но линковщик спотыкается на def-файле и пишет, что произошло 50 ошибок. Стоит убрать этот def-файл, как библиотека собирается. Сначала я подумал, что видимо def-файл у меня не соответствует нужному синтаксису, так как я засунул файл с Windows. Но при попытке найти в интернете правильный синтаксис def-файла под Unix я натолкнулся на сообщение, что для so-библиотек def-файл вообще не предусмотрен. Хм... я в недоумении.

Вопрос, как обычно решается эта проблема? Вроде бы без def-файла в либу будут экспортированы все функции... но как-то это не очень красиво выглядит, так как либа достаточно здоровая по размерам и чего там только нет. Короче, как сделать красиво, не превращая это в эпопею?

Именно так


Так и будет


Обычно не заморачиваются, а экспортируют все, что есть. Но если очень хочется, то это можно сделать через скрпт линкера (файл с расширением *.ld) секцию VERSION (см. info ld)
Или опцию --dynamic-list в командной строке

Odin_KG, обычно, подобные библиотеки делают вообще без def-файлов. Используя макросы DLL_PUBLIC, которые в зависимости от компилятора могут принимать разные значения (например: http://gcc.gnu.org/wiki/Visibility).

xvr
bsa

Благодарю за советы!


xvr


Хочется, но можно и обойтись. Зависит от сложности.


Посмотрел вот тут: http://www.scoberlin.de/content/media/http...ld_3.html#SEC39

VERS_1.1 {
     global:
         foo1;
     local:
         old*; 
         original*; 
         new*; 
};
Я правильно понимаю, что в секции global можно перечислить все функции, которые хотелось бы экспортировать, по аналогии с def-файлом?
Не могли бы вы дать пример полного ld-файла ? Я подозреваю, что если я оставлю только секцию с VER_1.1, то такое не прокатит.
Честно говоря, английский не является моим родным языком, хотя, конечно, приходится понимать, но с трудом 

И еще вопрос, как в Unix-е узнать, какие функции присутствуют внутри либы? (тестить же надо как-то). Подозреваю, что есть какая-то команда у терминала.


bsa

Я тут как понимаю... Windows по умолчанию не экспортирует ничего, а Unix, наоборот, всё. Значит на Windows-е __declspec(dllexport) ставится на тех функциях, которые надо экспортировать, а на Unix-e надо, наоборот, через __attribute__ ((visibility ("hidden"))) удалять функции, которые не нужно экспортировать. Функций много, поэтому это немыслимо. Или я неправильно понимаю?

Лучше не надо   Реальные *.ld файлы лежат рядом с линкером. 
Пользуйтесь параметром командной строки --dynamic-list, ему дают имя файла, где лежит внутренность VERS_1.1 из вашего примера.


Именно. А в local написать local: *


Если просто, то утилита nm. Если нужно ознакомится подробно с содержимым библиотеки, то objdump (ну и readelf для комплекта)

есть параметр у компилятора -fvisibility=hidden, который меняет видимость по умолчанию. В статье, на которую я дал тебе ссылку это написано.

xvr

Я пока сделал так: переписал свой def-файл, который я указывал в параметрах линкера codeblocks-а, в формат ld. Видимо переписал правильно, потому что сначала codeblocks ругался на ошибки - "не похож на linker script", а потом перестал.


Я видимо не совсем понимаю, что она показывает. Потому что подключаю я свой ld или нет она показывает примерно то же самое, несмотря на то, что я в настройках проекта вписал опции:
-fvisibility=hidden
-fvisibility-inlines-hidden

Если эти опции убрать, то создается впечатление, что список имен внутри дублируется, по крайней мере название моих экспортируемых функций начинает встречаться по 2 раза.
Вот к примеру функции, которые начинаются с Magic_  - это те, что мне нужны, а дальше начинается огромная тонная функций, которые начинаются с Z11 и т.д. 
00057b20 T Magic_StreamGetPosition
00057a20 T Magic_StreamOpenFile
00057a60 T Magic_StreamOpenMemory
00057c10 T Magic_StreamRead
00057cb0 T Magic_StreamSetMode
00057b60 T Magic_StreamSetPosition
00057ba0 T Magic_StreamWrite
000577c0 T Magic_UTF16to32
00057570 T Magic_UTF16to8
00057950 T Magic_UTF32to16
00057890 T Magic_UTF32to8
00057630 T Magic_UTF8to16
000576f0 T Magic_UTF8to32
00059ed0 T Magic_UnloadAllEmitters
00053ec0 T Magic_UnloadEmitter
000553f0 T Magic_UnlockParticlesType
00053f20 T Magic_Update
000eaef8 a _DYNAMIC
000eaff4 a _GLOBAL_OFFSET_TABLE_
00042da0 t _GLOBAL__sub_I__ZN9CResource10photo_sizeE
00042ce0 t _GLOBAL__sub_I_api_data
00042d50 t _GLOBAL__sub_I_debug
00042d20 t _GLOBAL__sub_I_move_mode
         w _Jv_RegisterClasses
         U _Unwind_Resume@@GCC_3.0
0005db00 T _Z10ClearBirthP11MAGIC_BIRTH
000452a0 T _Z10GetContextv
0009c130 T _Z10HSVtoRGB3Dj
0009c310 T _Z10HSVtoRGB3DjRjS_S_
0009bb80 T _Z10IsTimelinev
0009caf0 T _Z11GetPathOnlyR12CMagicString
0009be00 T _Z11GetRndDwordjj
0009bcf0 T _Z11GetRndFloatff
0009bce0 T _Z11GetRndIndexv
0009bcd0 T _Z11SetRndIndexj
0009bb60 T _Z11fopen_magicPKcS0_
00083e70 T _Z12BezierDivideP9PSET_DATAS0_iPfS0_f
00083de0 T _Z12BezierDivideP9PSET_DATAS0_iS0_f
00083960 T _Z12BezierDividefP9PSET_DATAS0_S0_f
0009c6d0 T _Z12GetExtensionR12CMagicString
0009bd40 T _Z12GetRndDoubledd


Просидел сегодня полночи, пробовал на мой взгляд все возможные варианты, но либо я чего-то не понимаю, либо одно из двух  Утилита nm показывает примерно один и тот же набор символов.
Если я добавляю свой ld со списком, то вместо уменьшения размера so-библиотеки, а получаю небольшое увеличение. При этом я вижу, что среди символов начинает встречаться моя версия в виде:   A         VERS_2.21

Это замангленные С++ имена функций.
Попробуйте objdump -T - он покажет реальные символы, которые экспортирует ваша библиотека. nm показывает немного больше, т.к. он показывает все символы из модуля, а не только используемые для динамической линковки (для elf файла это не одно и тоже!). Остальные символы можно удалить командой strip