Re: [devel] samba-3.0.21c-alt1: rebuild failed

Re: [devel] samba-3.0.21c-alt1: rebuild failed

[Alexander Bokovoy]

QA Team Robot wrote:
> Status: rebuild failed.
> Please investigate.
> 
> Why:
> 
> verify-elf: WARNING: ./usr/lib/samba/pdb/xml.so: undefined symbol: smb_register_passdb
> verify-elf: WARNING: ./usr/lib/samba/pdb/xml.so: undefined symbol: pdb_get_workstations
> verify-elf: WARNING: ./usr/lib/samba/pdb/xml.so: undefined symbol: talloc_strdup
> verify-elf: WARNING: ./usr/lib/samba/pdb/xml.so: undefined symbol: pdb_get_pass_must_change_time
Эти (и все остальные) -- плагины, использующие функции, которые
предоставляет /usr/sbin/smbd, так что тут символам положено быть
неопределенными.

Как "давить" verify-elf в /usr/lib/samba ?

> verify-elf: WARNING: ./usr/bin/smbwrapper.so: undefined symbol: secrets_fetch_machine_password
> verify-elf: WARNING: ./usr/bin/smbwrapper.so: undefined symbol: secrets_fetch
А этого зверя вообще придавить надо, чтобы в пакет не попадал.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] samba-3.0.21c-alt1: rebuild failed

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

On Sat, Mar 18, 2006 at 10:48:30PM +0300, Alexander Bokovoy wrote:
> QA Team Robot wrote:
> > Status: rebuild failed.
> > Please investigate.
> > 
> > Why:
> > 
> > verify-elf: WARNING: ./usr/lib/samba/pdb/xml.so: undefined symbol: smb_register_passdb
> > verify-elf: WARNING: ./usr/lib/samba/pdb/xml.so: undefined symbol: pdb_get_workstations
> > verify-elf: WARNING: ./usr/lib/samba/pdb/xml.so: undefined symbol: talloc_strdup
> > verify-elf: WARNING: ./usr/lib/samba/pdb/xml.so: undefined symbol: pdb_get_pass_must_change_time
> Эти (и все остальные) -- плагины, использующие функции, которые
> предоставляет /usr/sbin/smbd, так что тут символам положено быть
> неопределенными.
> 
> Как "давить" verify-elf в /usr/lib/samba ?

Это warning'и, их не надо давить.

> > verify-elf: WARNING: ./usr/bin/smbwrapper.so: undefined symbol: secrets_fetch_machine_password
> > verify-elf: WARNING: ./usr/bin/smbwrapper.so: undefined symbol: secrets_fetch
> А этого зверя вообще придавить надо, чтобы в пакет не попадал.

Это точно.

А не собрался пакет по другой причине:

verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: yperr_string
verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: secrets_fetch_machine_password
verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: secrets_fetch
verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: secrets_delete
verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: secrets_store
verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: yp_get_default_domain
verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: yp_match

Это, конечно, можно задавить, но лучше исправить.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] samba-3.0.21c-alt1: rebuild failed

[Sviatoslav Sviridov]

[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]

Dmitry V. Levin пишет:
> Это warning'и, их не надо давить.
>   

Кстати, а ручка есть какая-нить, чтобы временно отключать вывод таких 
варнингов? чтобы проще было еггоги сначала заметить и исправить? :)
> ...
> А не собрался пакет по другой причине:
>
> verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: yperr_string
> verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: secrets_fetch_machine_password
> verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: secrets_fetch
> verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: secrets_delete
> verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: secrets_store
> verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: yp_get_default_domain
> verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: yp_match
>
> Это, конечно, можно задавить, но лучше исправить.
>   

Вот подобное и в subversion-1.3.1 сейчас вылезло. Ну да это исправить 
можно. Там выявился другой баг:
/usr/lib/libsvn_swig_perl-1.so.0 использует символ, который определен в 
/usr/lib/perl5/vendor_perl/i386-linux/auto/SVN/_Core/_Core.so. Причем 
этот самый _Core.so слинкован с lib_svn_swig_perl, а libsvn_swig_perl 
никем другим больше и не используется, и поэтому во время выполнения 
проблем не возникает.

Как правильно поступить в данной ситуации?

Исходные данные:
subversion/bindings/swig/core.i определяет

static apr_pool_t *current_pool = 0;
                             
SVN_SWIGEXPORT(apr_pool_t *)
svn_swig_pl_get_current_pool (void)
{                            
  return current_pool;
}                   

Эта функция используется в 
subversion/bindings/swig/perl/libsvn_swig_perl/swigutil_pl.c.


-- 
Best regards,
Sviatoslav Sviridov
--
The typical page layout program is nothing more than an electronic
light table for cutting and pasting documents.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] libsvn_swig_perl

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]

On Sun, Mar 19, 2006 at 01:35:56AM +0200, Sviatoslav Sviridov wrote:
> Dmitry V. Levin пишет:
> >Это warning'и, их не надо давить.
> 
> Кстати, а ручка есть какая-нить, чтобы временно отключать вывод таких 
> варнингов? чтобы проще было еггоги сначала заметить и исправить? :)

Ручки нет, пока не придумали.

[...]
> >verify-elf: ERROR: ./lib/libnss_wins.so: undefined symbol: yp_match
> >
> >Это, конечно, можно задавить, но лучше исправить.
> 
> Вот подобное и в subversion-1.3.1 сейчас вылезло. Ну да это исправить 
> можно. Там выявился другой баг:
> /usr/lib/libsvn_swig_perl-1.so.0 использует символ, который определен в 
> /usr/lib/perl5/vendor_perl/i386-linux/auto/SVN/_Core/_Core.so. Причем 
> этот самый _Core.so слинкован с lib_svn_swig_perl, а libsvn_swig_perl 
> никем другим больше и не используется, и поэтому во время выполнения 
> проблем не возникает.

С libsvn_swig_perl никто в принципе не линкуется или просто сейчас нет
пользователей?

> Как правильно поступить в данной ситуации?

Попробовать перенести символ в библиотеку?
Может, спросить авторов, зачем они сделали шиворот-навыворот?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] libsvn_swig_perl

[Sviatoslav Sviridov]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

Dmitry V. Levin пишет:
> [...]
>   
>> Вот подобное и в subversion-1.3.1 сейчас вылезло. Ну да это исправить 
>> можно. Там выявился другой баг:
>> /usr/lib/libsvn_swig_perl-1.so.0 использует символ, который определен в 
>> /usr/lib/perl5/vendor_perl/i386-linux/auto/SVN/_Core/_Core.so. Причем 
>> этот самый _Core.so слинкован с lib_svn_swig_perl, а libsvn_swig_perl 
>> никем другим больше и не используется, и поэтому во время выполнения 
>> проблем не возникает.
>>     
>
> С libsvn_swig_perl никто в принципе не линкуется или просто сейчас нет
> пользователей?
>   

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

Да, это, наверно, будет наиболее правильный вариант

> Может, спросить авторов, зачем они сделали шиворот-навыворот?
>   

Попробую...

-- 
Best regards,
Sviatoslav Sviridov
--
May all your PUSHes be POPped.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] samba-3.0.21c-alt1: rebuild failed

[Sviatoslav Sviridov]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

Sviatoslav Sviridov пишет:
> ...
> Вот подобное и в subversion-1.3.1 сейчас вылезло. Ну да это исправить 
> можно. 

А все же интересная ситуация получается...
libsvn_swig_py, libsvn_swig_perl и libsvn_swig_ruby созданы для 
использования только из соответствующих swig-биндингов (IMHO).  Лежат 
они в /usr/lib, но способ их использования на данный момент больше похож 
на способ использования плагинов. Они не линкуются с libpython, libperl 
и libruby, но в рантайме все необходимые символы уже присутствуют, 
поскольку нужные библиотеки загружены соответствующим интерпретатором... 
И что же будет лучше: слинковать их с нужными библиотеками или вынести 
их из /usr/lib? В последнем случае - куда вынести и как сделать из 
видимыми для биндингов (rpath?)?


-- 
Best regards,
Sviatoslav Sviridov
--
May all your PUSHes be POPped.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] samba-3.0.21c-alt1: rebuild failed

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

On Sun, Mar 19, 2006 at 02:18:52AM +0200, Sviatoslav Sviridov wrote:
> Sviatoslav Sviridov пишет:
> >...
> >Вот подобное и в subversion-1.3.1 сейчас вылезло. Ну да это исправить 
> >можно. 
> 
> А все же интересная ситуация получается...
> libsvn_swig_py, libsvn_swig_perl и libsvn_swig_ruby созданы для 
> использования только из соответствующих swig-биндингов (IMHO).  Лежат 
> они в /usr/lib, но способ их использования на данный момент больше похож 
> на способ использования плагинов. Они не линкуются с libpython, libperl 
> и libruby, но в рантайме все необходимые символы уже присутствуют, 
> поскольку нужные библиотеки загружены соответствующим интерпретатором... 
> И что же будет лучше: слинковать их с нужными библиотеками или вынести 
> их из /usr/lib? В последнем случае - куда вынести и как сделать из 
> видимыми для биндингов (rpath?)?

Ситуация не очевидная, я бы спросил авторов этих привязок.
Если они ничего не посоветуют, то лучше перенести эти небибилиотеки из
%_libdir в какой-нибудь %_libdir/libsvn_swig и добавить в привязки rpath -
это будет проще и логичнее.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] samba-3.0.21c-alt1: rebuild failed

[Sviatoslav Sviridov]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

Dmitry V. Levin пишет:
> On Sun, Mar 19, 2006 at 02:18:52AM +0200, Sviatoslav Sviridov wrote:
>   
>> ...
>>     
>> И что же будет лучше: слинковать их с нужными библиотеками или вынести 
>> их из /usr/lib? В последнем случае - куда вынести и как сделать из 
>> видимыми для биндингов (rpath?)?
>>     
>
> Ситуация не очевидная, я бы спросил авторов этих привязок.
> Если они ничего не посоветуют, то лучше перенести эти небибилиотеки из
> %_libdir в какой-нибудь %_libdir/libsvn_swig и добавить в привязки rpath -
> это будет проще и логичнее.
>   

Итого, в апстриме говорят, что привязок не должен использовать 
libsvn_swig_*, так что будем выносить...

-- 
Best regards,
Sviatoslav Sviridov
--
"Nine years of ballet, asshole."
-- Shelly Long, to the bad guy after making a jump over a gorge that he
   couldn't quite, in "Outrageous Fortune"


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] samba-3.0.21c-alt1: rebuild failed

[Sviatoslav Sviridov]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

Sviatoslav Sviridov wrote on 3/20/2006 10:08 PM:
> Dmitry V. Levin пишет:
>> On Sun, Mar 19, 2006 at 02:18:52AM +0200, Sviatoslav Sviridov wrote:
>>  
>>> ...
>>>     И что же будет лучше: слинковать их с нужными библиотеками или
>>> вынести их из /usr/lib? В последнем случае - куда вынести и как
>>> сделать из видимыми для биндингов (rpath?)?
>>>     
>>
>> Ситуация не очевидная, я бы спросил авторов этих привязок.
>> Если они ничего не посоветуют, то лучше перенести эти небибилиотеки из
>> %_libdir в какой-нибудь %_libdir/libsvn_swig и добавить в привязки
>> rpath -
>> это будет проще и логичнее.
>>   
>
> Итого, в апстриме говорят, что привязок не должен использовать
> libsvn_swig_*, так что будем выносить...
И тут возникает вопрос: а как это правильно сделать?
Будет ли политкорректно, если я не буду трогать процесс сборки, а в
конце стадии %install перемещю требуемые библиотеки и изменю rpath (при
помощи chrpath) для необходимых модулей?

-- 
Best Regards,
Sviatoslav Sviridov


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [devel] samba-3.0.21c-alt1: rebuild failed

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

On Tue, Mar 21, 2006 at 12:39:26PM +0200, Sviatoslav Sviridov wrote:
> Sviatoslav Sviridov wrote on 3/20/2006 10:08 PM:
> > Dmitry V. Levin пишет:
> >> On Sun, Mar 19, 2006 at 02:18:52AM +0200, Sviatoslav Sviridov wrote:
> >>  
> >>> ...
> >>>     И что же будет лучше: слинковать их с нужными библиотеками или
> >>> вынести их из /usr/lib? В последнем случае - куда вынести и как
> >>> сделать из видимыми для биндингов (rpath?)?
> >>>     
> >>
> >> Ситуация не очевидная, я бы спросил авторов этих привязок.
> >> Если они ничего не посоветуют, то лучше перенести эти небибилиотеки из
> >> %_libdir в какой-нибудь %_libdir/libsvn_swig и добавить в привязки
> >> rpath -
> >> это будет проще и логичнее.
> >>   
> >
> > Итого, в апстриме говорят, что привязок не должен использовать
> > libsvn_swig_*, так что будем выносить...
> И тут возникает вопрос: а как это правильно сделать?
> Будет ли политкорректно, если я не буду трогать процесс сборки, а в
> конце стадии %install перемещю требуемые библиотеки и изменю rpath (при
> помощи chrpath) для необходимых модулей?

chrpath не умеет добавлять rpath, так что лучше будет сделать это на
стадии сборки.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] samba-3.0.21c-alt1: rebuild failed

[Sviatoslav Sviridov]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

Dmitry V. Levin пишет:
>> И тут возникает вопрос: а как это правильно сделать?
>> Будет ли политкорректно, если я не буду трогать процесс сборки, а в
>> конце стадии %install перемещю требуемые библиотеки и изменю rpath (при
>> помощи chrpath) для необходимых модулей?
>>     
>
> chrpath не умеет добавлять rpath, так что лучше будет сделать это на
> стадии сборки.
>   
В процессе разборок также вот с чем столкнулся:

В Makefile обнаружились переменные, которые задают каталог для установки 
libsvn_swig_*. По-умолчанию там был @libdir@, указал 
@libdir@/libsvn_swig, но при установке ругается:

cd subversion/bindings/swig/python/libsvn_swig_py ; /bin/sh 
/usr/src/RPM/BUILD/subversion-1.3.1/libtool --mode=install /bin/install 
-p libsvn_swig_py-1.la 
/usr/src/tmp/subversion-buildroot/usr/lib/libsvn_swig/libsvn_swig_py-1.la
libtool: install: error: cannot install `libsvn_swig_py-1.la' to a 
directory not ending in /usr/lib

Такая же ругань вылезла, когда попытался устанавливать питоновские 
модули с переопределением нужных каталогов при вызове make (только там 
вместо /usr/lib другое значение).

Фактически, в .la файле имеется libdir=/usr/lib (во втором случае, 
соответственно, другое значение), libtool не дает установить библиотеку 
в другое место.

Так вот вопрос: как правильно линковать библиотеки, чтобы libdir в .la 
принимал тербуемые значения? Вроде бы make libdir="/my/lib/dir" target 
должно прокатить (проверка в процессе)... Это будет корректно? (в 
случае, в Makefile имеется таргет для сборки именно того, что необходимо 
собирать с этим libdir)

-- 
Best regards,
Sviatoslav Sviridov
--
Debug is human, de-fix divine.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] samba-3.0.21c-alt1: rebuild failed

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

On Wed, Mar 22, 2006 at 01:22:59AM +0200, Sviatoslav Sviridov wrote:
> Dmitry V. Levin пишет:
> >>И тут возникает вопрос: а как это правильно сделать?
> >>Будет ли политкорректно, если я не буду трогать процесс сборки, а в
> >>конце стадии %install перемещю требуемые библиотеки и изменю rpath (при
> >>помощи chrpath) для необходимых модулей?
> >>    
> >
> >chrpath не умеет добавлять rpath, так что лучше будет сделать это на
> >стадии сборки.
> >  
> В процессе разборок также вот с чем столкнулся:
> 
> В Makefile обнаружились переменные, которые задают каталог для установки 
> libsvn_swig_*. По-умолчанию там был @libdir@, указал 
> @libdir@/libsvn_swig, но при установке ругается:

Вот их лучше не менять, иначе придётся много чего ещё менять.

> Так вот вопрос: как правильно линковать библиотеки, чтобы libdir в .la 
> принимал тербуемые значения?

А зачем заботиться о значениях в .la?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] samba-3.0.21c-alt1: rebuild failed

[Sviatoslav Sviridov]

[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]

Dmitry V. Levin пишет:
> On Wed, Mar 22, 2006 at 01:22:59AM +0200, Sviatoslav Sviridov wrote:
>   
>> Dmitry V. Levin пишет:
>>     
>>>> И тут возникает вопрос: а как это правильно сделать?
>>>> Будет ли политкорректно, если я не буду трогать процесс сборки, а в
>>>> конце стадии %install перемещю требуемые библиотеки и изменю rpath (при
>>>> помощи chrpath) для необходимых модулей?
>>>>    
>>>>         
>>> chrpath не умеет добавлять rpath, так что лучше будет сделать это на
>>> стадии сборки.
>>>  
>>>       
>> В процессе разборок также вот с чем столкнулся:
>>
>> В Makefile обнаружились переменные, которые задают каталог для установки 
>> libsvn_swig_*. По-умолчанию там был @libdir@, указал 
>> @libdir@/libsvn_swig, но при установке ругается:
>>     
>
> Вот их лучше не менять, иначе придётся много чего ещё менять.
>   

Почему? Вернее, а что это "много еще чего"? Там по одной переменной для 
каждой библиотеки из libsvn_swig_*...
Или все же лучше их собрать нормально и потом руками скопировать?

>> Так вот вопрос: как правильно линковать библиотеки, чтобы libdir в .la 
>> принимал тербуемые значения?
>>     
>
> А зачем заботиться о значениях в .la?
>   

[в случае наличия укзанной замены в Makefile] Чтобы библиотеки 
установились при помощи libtool. Он там внутри себя делает
. libbla_bla.la
и потом смотрит - совпадает ли место назначения с libdir, и если не 
совпадает - завершается с ошибкой.

Еще один побочный [положительный] эффект от указания libdbir при сборке 
биндингов - в биндингах сразу присутствует нужный rpath среди других 
значений :) правда не знаю, сохранится ли он после того, как будет 
произведена установка в DESTDIR...
А вот тот rpath, что передается в качестве параметра libtool'у при 
линковке (тоже было изначально в Makefile), в результирующих модулях не 
фигурирует...

-- 
Best regards,
Sviatoslav Sviridov
--
Debug is human, de-fix divine.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] samba-3.0.21c-alt1: rebuild failed

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

On Sat, Mar 18, 2006 at 10:48:30PM +0300, Alexander Bokovoy wrote:
> > verify-elf: WARNING: ./usr/lib/samba/pdb/xml.so: undefined symbol: smb_register_passdb
> > verify-elf: WARNING: ./usr/lib/samba/pdb/xml.so: undefined symbol: pdb_get_workstations
> > verify-elf: WARNING: ./usr/lib/samba/pdb/xml.so: undefined symbol: talloc_strdup
> > verify-elf: WARNING: ./usr/lib/samba/pdb/xml.so: undefined symbol: pdb_get_pass_must_change_time
> Эти (и все остальные) -- плагины, использующие функции, которые
> предоставляет /usr/sbin/smbd, так что тут символам положено быть
> неопределенными.

Хм.  Вот чего не понимаю.  Если /usr/sbin/smbd стрипнуть как следует, он
эти функции предоставлять не будет, и всё отвалится?

> Как "давить" verify-elf в /usr/lib/samba ?
> > verify-elf: WARNING: ./usr/bin/smbwrapper.so: undefined symbol: secrets_fetch_machine_password
> > verify-elf: WARNING: ./usr/bin/smbwrapper.so: undefined symbol: secrets_fetch
> А этого зверя вообще придавить надо, чтобы в пакет не попадал.

А я над ним голову ломал, какая от него польза...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] samba-3.0.21c-alt1: rebuild failed

[Alexander Bokovoy]

Alexey Tourbin пишет:
> On Sat, Mar 18, 2006 at 10:48:30PM +0300, Alexander Bokovoy wrote:
>>> verify-elf: WARNING: ./usr/lib/samba/pdb/xml.so: undefined
>>> symbol: smb_register_passdb verify-elf: WARNING:
>>> ./usr/lib/samba/pdb/xml.so: undefined symbol:
>>> pdb_get_workstations verify-elf: WARNING:
>>> ./usr/lib/samba/pdb/xml.so: undefined symbol: talloc_strdup 
>>> verify-elf: WARNING: ./usr/lib/samba/pdb/xml.so: undefined
>>> symbol: pdb_get_pass_must_change_time
>> Эти (и все остальные) -- плагины, использующие функции, которые 
>> предоставляет /usr/sbin/smbd, так что тут символам положено быть 
>> неопределенными.
> 
> Хм.  Вот чего не понимаю.  Если /usr/sbin/smbd стрипнуть как следует,
> он эти функции предоставлять не будет, и всё отвалится?
Приведи пример, как собрать эти плагины так, чтобы они не хотели символы
из smbd и работали.


>> Как "давить" verify-elf в /usr/lib/samba ?
>>> verify-elf: WARNING: ./usr/bin/smbwrapper.so: undefined symbol:
>>> secrets_fetch_machine_password verify-elf: WARNING:
>>> ./usr/bin/smbwrapper.so: undefined symbol: secrets_fetch
>> А этого зверя вообще придавить надо, чтобы в пакет не попадал.
> 
> А я над ним голову ломал, какая от него польза...
После изменений в glibc, которые разнесли работу некоторых функций через
публичные интерфейсы и приватные, переопределение fopen/fclose и прочих
еще ничего не дает с точки зрения полного перекрытия операций --
некоторые операции в glibc все равно будут использовать внутренние
реализации, к которым в конечном итоге и обращаются glibc-шные же
fopen/fclose et al. Так что толку от таких оберток становится все меньше.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/