Посмотрел... Это как ИМПОРТИРОВАТЬ функции из других библиотек... А у меня своя. Должна экспортировать всего три функции, а гонит все паблик-символы :-))). Я несколько раз просамтривал ман по линкеру - ничего, можно только отрубить все...
Первый раз слышу, что паблик-символы надо куда-то экспортировать.
Используемые либой символы автоматически суются в таблицу, при желании
можешь засунуть туда вообще все опцией -export-dynamic.
Если тебе нужно "открыть наружу" только 3 функции, объяви остальные
static. Но они все равно останутся в символах, поскольку должны же
как-то вызываться "снаружи" "открытыми" функциями!
В манах от ld пишут, что экспортировать можно или через атрибуты, или с помощью файла .DEF (это, по всей видимости, относится к Windows). Если через атрибуты ничего не экспортируется, то они пишут, что ld экспортирует всё. Так что, попробуй порыться в info gcc и найти атрибут для экспорта.
2justme (*) (2002-03-14 21:01:24.0):
А что все это такое значит? Ткни где почитать.
Я так думал, что все разрешенные не- static символы автоматически экспортируются -
т.е. заносятся в таблицу динамических символов - и это правильно, иначе поведение
динамической либы будет отличным от той же, но статической. Разве не так?
Я понимаю опцию -export-dynamic в ld, которая экспортирует НЕразрешенные символы тоже
- это бывает необходимо для "обратного" связывания, когда некоторые символы могут быть
разрешены в программе. Но какой смысл в "позднем связывании" символа с областью
видимости ?
жХРЮРЮ ХГ man ld - ХКХ ЩРН МЕ НМН?
--export-all-symbols
If given, all global symbols in the objects used to
build a DLL will be exported by the DLL. Note that
this is the default if there otherwise wouldn't be any
exported symbols. When symbols are explicitly
exported via DEF files or implicitly exported via
function attributes, the default is to not export any╜
thing else unless this option is given. Note that the
symbols "DllMain@12", "DllEntryPoint@0", "DllMainCRT╜
Startup@12", and "impure_ptr" will not be automati╜
cally exported. Also, symbols imported from other
DLLs will not be re-exported, nor will symbols speci╜
fying the DLL's internal layout such as those begin╜
ning with "_head_" or ending with "_iname". In addi╜
tion, no symbols from "libgcc", "libstd++", "lib╜
mingw32", or "crtX.o" will be exported. Symbols whose
names begin with "__rtti_" or "__builtin_" will not be
exported, to help with C++ DLLs. Finally, there is an
extensive list of cygwin-private symbols that are not
exported (obviously, this applies on when building
DLLs for cygwin targets). These cygwin-excludes are:
"_cygwin_dll_entry@12", "_cygwin_crt0_common@8",
"_cygwin_noncygwin_dll_entry@12", "_fmode",
"_impure_ptr", "cygwin_attach_dll", "cygwin_premain0",
"cygwin_premain1", "cygwin_premain2", "cygwin_pre╜
main3", and "environ".
Ну это, типа, про DLL под Win32 сказано. А там, как я понимаю, несколько
иначе все реализовано, с учетом IPC, на котором НТя бегает. По Юнихом же,
как я понимаю, so - просто странслированный код, размещаемый в памяти.
А, вообще, я - не спец. Рассказал бы кто, где почитать быстренько...