LINUX.ORG.RU

Ответ на: комментарий от Die-Hard

Посмотрел... Это как ИМПОРТИРОВАТЬ функции из других библиотек... А у меня своя. Должна экспортировать всего три функции, а гонит все паблик-символы :-))). Я несколько раз просамтривал ман по линкеру - ничего, можно только отрубить все...

anonymous
()
Ответ на: комментарий от anonymous

Первый раз слышу, что паблик-символы надо куда-то экспортировать.
Используемые либой символы автоматически суются в таблицу, при желании
можешь засунуть туда вообще все опцией -export-dynamic.

Если тебе нужно "открыть наружу" только 3 функции, объяви остальные
static. Но они все равно останутся в символах, поскольку должны же
как-то вызываться "снаружи" "открытыми" функциями!

Die-Hard ★★★★★
()

В манах от ld пишут, что экспортировать можно или через атрибуты, или с помощью файла .DEF (это, по всей видимости, относится к Windows). Если через атрибуты ничего не экспортируется, то они пишут, что ld экспортирует всё. Так что, попробуй порыться в info gcc и найти атрибут для экспорта.

justme
()
Ответ на: комментарий от justme

2justme (*) (2002-03-14 21:01:24.0):
А что все это такое значит? Ткни где почитать.

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

Я понимаю опцию -export-dynamic в ld, которая экспортирует НЕразрешенные символы тоже
- это бывает необходимо для "обратного" связывания, когда некоторые символы могут быть
разрешены в программе. Но какой смысл в "позднем связывании" символа с областью
видимости ?

Или я чего-то не понимаю?

Die-Hard ★★★★★
()

жХРЮРЮ ХГ 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".

justme
()
Ответ на: комментарий от justme


Ну это, типа, про DLL под Win32 сказано. А там, как я понимаю, несколько
иначе все реализовано, с учетом IPC, на котором НТя бегает. По Юнихом же,
как я понимаю, so - просто странслированный код, размещаемый в памяти.

А, вообще, я - не спец. Рассказал бы кто, где почитать быстренько...

Die-Hard ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.