[devel] Rebuild to remove redundant libpython2.7 dependency

[devel] Rebuild to remove redundant libpython2.7 dependency

[Yuri N. Sedunov]

В python-module-pygobject{,3} кроме модулей под %python_sitelibdir есть
еще и библиотеки -- %_libdir/libpyglib-2.0-python.so и %
_libdir/libpyglib-gi-2.0-python.so, соответственно, которые как и модули
в лучших традициях недавнего прошлого были слинкованы с libpython
принудительно. 

Разумеется, verify-elf не пропускает недолинкованные библиотеки.

Не подскажут ли лучшие питонустроители нашего Сизифа, как следует
поступить?

-- 
Yuri N. Sedunov

Re: [devel] Rebuild to remove redundant libpython2.7 dependency

[Vitaly Kuznetsov]

On Fri, 13 Apr 2012 14:36:01 +0400, Yuri N. Sedunov wrote:
> В python-module-pygobject{,3} кроме модулей под %python_sitelibdir 
> есть
> еще и библиотеки -- %_libdir/libpyglib-2.0-python.so и %
> _libdir/libpyglib-gi-2.0-python.so, соответственно, которые как и 
> модули
> в лучших традициях недавнего прошлого были слинкованы с libpython
> принудительно.
>
> Разумеется, verify-elf не пропускает недолинкованные библиотеки.
>
> Не подскажут ли лучшие питонустроители нашего Сизифа, как следует
> поступить?

Лучшие питоноустроители, как известно, давно вывелись :) А если 
серьёзно, то теоретическая необходимость их линковки с libpython зависит 
от того, кто этими библиотеками пользуется:
1) Если ими пользуются модули питона, то лучше не линковать из с 
libpython -- модуль может использоваться и под /usr/bin/python. Как это 
обойти в verify-elf - вопрос. Теоретически, как и модули питона, такие 
библиотеки надо проверять с запрелоаденным libpython.
2) Если ими пользуются только некие программы, слинкованные с 
libpython, то линковку лучше оставить.
3) Если ими пользуются и модули питона, и некие программы, слинкованные 
с libpython, то случай тяжёлый, проблемы (теоретически) возможны и при 
линковке, и при её отсутствии. Я бы посмотрел на то, как поступили в 
debian -- у них аналогичный нашему "распил питона".

Re: [devel] Rebuild to remove redundant libpython2.7 dependency

[Yuri N. Sedunov]

В Птн, 13/04/2012 в 14:56 +0400, Vitaly Kuznetsov пишет:
> On Fri, 13 Apr 2012 14:36:01 +0400, Yuri N. Sedunov wrote:
> > В python-module-pygobject{,3} кроме модулей под %python_sitelibdir 
> > есть
> > еще и библиотеки -- %_libdir/libpyglib-2.0-python.so и %
> > _libdir/libpyglib-gi-2.0-python.so, соответственно, которые как и 
> > модули
> > в лучших традициях недавнего прошлого были слинкованы с libpython
> > принудительно.
> >
> > Разумеется, verify-elf не пропускает недолинкованные библиотеки.
> >
> > Не подскажут ли лучшие питонустроители нашего Сизифа, как следует
> > поступить?
> 
> Лучшие питоноустроители, как известно, давно вывелись :) А если 
> серьёзно, то теоретическая необходимость их линковки с libpython зависит 
> от того, кто этими библиотеками пользуется:
> 1) Если ими пользуются модули питона, то лучше не линковать из с 
> libpython -- модуль может использоваться и под /usr/bin/python. Как это 
> обойти в verify-elf - вопрос. Теоретически, как и модули питона, такие 
> библиотеки надо проверять с запрелоаденным libpython.
> 2) Если ими пользуются только некие программы, слинкованные с 
> libpython, то линковку лучше оставить.
> 3) Если ими пользуются и модули питона, и некие программы, слинкованные 
> с libpython, то случай тяжёлый, проблемы (теоретически) возможны и при 
> линковке, и при её отсутствии. 

С этими библиотеками никто не линкуется.


> Я бы посмотрел на то, как поступили в 
> debian -- у них аналогичный нашему "распил питона".

В дебианах собрано как есть, -- видимо, надо готовить verify-elf.



-- 
Yuri N. Sedunov

Re: [devel] Rebuild to remove redundant libpython2.7 dependency

[Dmitry V. Levin]

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

On Fri, Apr 13, 2012 at 03:32:25PM +0400, Yuri N. Sedunov wrote:
> В Птн, 13/04/2012 в 14:56 +0400, Vitaly Kuznetsov пишет:
> > On Fri, 13 Apr 2012 14:36:01 +0400, Yuri N. Sedunov wrote:
> > > В python-module-pygobject{,3} кроме модулей под %python_sitelibdir 
> > > есть
> > > еще и библиотеки -- %_libdir/libpyglib-2.0-python.so и %
> > > _libdir/libpyglib-gi-2.0-python.so, соответственно, которые как и 
> > > модули
> > > в лучших традициях недавнего прошлого были слинкованы с libpython
> > > принудительно.
> > >
> > > Разумеется, verify-elf не пропускает недолинкованные библиотеки.
> > >
> > > Не подскажут ли лучшие питонустроители нашего Сизифа, как следует
> > > поступить?
> > 
> > Лучшие питоноустроители, как известно, давно вывелись :) А если 
> > серьёзно, то теоретическая необходимость их линковки с libpython зависит 
> > от того, кто этими библиотеками пользуется:
> > 1) Если ими пользуются модули питона, то лучше не линковать из с 
> > libpython -- модуль может использоваться и под /usr/bin/python. Как это 
> > обойти в verify-elf - вопрос. Теоретически, как и модули питона, такие 
> > библиотеки надо проверять с запрелоаденным libpython.
> > 2) Если ими пользуются только некие программы, слинкованные с 
> > libpython, то линковку лучше оставить.
> > 3) Если ими пользуются и модули питона, и некие программы, слинкованные 
> > с libpython, то случай тяжёлый, проблемы (теоретически) возможны и при 
> > линковке, и при её отсутствии. 
> 
> С этими библиотеками никто не линкуется.

Каким образом тогда эти библиотеки предполагается использовать?


-- 
ldv

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

Re: [devel] Rebuild to remove redundant libpython2.7 dependency

[Yuri N. Sedunov]

В Птн, 13/04/2012 в 16:18 +0400, Dmitry V. Levin пишет:
> On Fri, Apr 13, 2012 at 03:32:25PM +0400, Yuri N. Sedunov wrote:
> > В Птн, 13/04/2012 в 14:56 +0400, Vitaly Kuznetsov пишет:
> > > On Fri, 13 Apr 2012 14:36:01 +0400, Yuri N. Sedunov wrote:
> > > > В python-module-pygobject{,3} кроме модулей под %python_sitelibdir 
> > > > есть
> > > > еще и библиотеки -- %_libdir/libpyglib-2.0-python.so и %
> > > > _libdir/libpyglib-gi-2.0-python.so, соответственно, которые как и 
> > > > модули
> > > > в лучших традициях недавнего прошлого были слинкованы с libpython
> > > > принудительно.
> > > >
> > > > Разумеется, verify-elf не пропускает недолинкованные библиотеки.
> > > >
> > > > Не подскажут ли лучшие питонустроители нашего Сизифа, как следует
> > > > поступить?
> > > 
> > > Лучшие питоноустроители, как известно, давно вывелись :) А если 
> > > серьёзно, то теоретическая необходимость их линковки с libpython зависит 
> > > от того, кто этими библиотеками пользуется:
> > > 1) Если ими пользуются модули питона, то лучше не линковать из с 
> > > libpython -- модуль может использоваться и под /usr/bin/python. Как это 
> > > обойти в verify-elf - вопрос. Теоретически, как и модули питона, такие 
> > > библиотеки надо проверять с запрелоаденным libpython.
> > > 2) Если ими пользуются только некие программы, слинкованные с 
> > > libpython, то линковку лучше оставить.
> > > 3) Если ми пользуются и модули питона, и некие программы, слинкованные 
> > > с libpython, то случай тяжёлый, проблемы (теоретически) возможны и при 
> > > линковке, и при её отсутствии. 
> > 
> > С этими библиотеками никто не линкуется.
> 
> Каким образом тогда эти библиотеки предполагается использовать?

Сказанное выше, о том, что никто не линкуется с этими библиотеками,
следует понимать так, что никто не линкуется с этими библиотеками кроме
питон-модулей в самих python-module-pygobject*. Т.е _сторонние_
питон-модули и программы используют модули из python-module-pygobject*,
слинкованные с этими библиотеками.

Еще вопросы?


-- 
Yuri N. Sedunov

Re: [devel] Rebuild to remove redundant libpython2.7 dependency

[Vitaly Kuznetsov]

On Fri, 13 Apr 2012 18:39:19 +0400, Yuri N. Sedunov wrote:
> В Птн, 13/04/2012 в 16:18 +0400, Dmitry V. Levin пишет:
>> On Fri, Apr 13, 2012 at 03:32:25PM +0400, Yuri N. Sedunov wrote:
>> > В Птн, 13/04/2012 в 14:56 +0400, Vitaly Kuznetsov пишет:
>> > > On Fri, 13 Apr 2012 14:36:01 +0400, Yuri N. Sedunov wrote:
>> > > > В python-module-pygobject{,3} кроме модулей под 
>> %python_sitelibdir
>> > > > есть
>> > > > еще и библиотеки -- %_libdir/libpyglib-2.0-python.so и %
>> > > > _libdir/libpyglib-gi-2.0-python.so, соответственно, которые 
>> как и
>> > > > модули
>> > > > в лучших традициях недавнего прошлого были слинкованы с 
>> libpython
>> > > > принудительно.
>> > > >
>> > > > Разумеется, verify-elf не пропускает недолинкованные 
>> библиотеки.
>> > > >
>> > > > Не подскажут ли лучшие питонустроители нашего Сизифа, как 
>> следует
>> > > > поступить?
>> > >
>> > > Лучшие питоноустроители, как известно, давно вывелись :) А если
>> > > серьёзно, то теоретическая необходимость их линковки с libpython 
>> зависит
>> > > от того, кто этими библиотеками пользуется:
>> > > 1) Если ими пользуются модули питона, то лучше не линковать из с
>> > > libpython -- модуль может использоваться и под /usr/bin/python. 
>> Как это
>> > > обойти в verify-elf - вопрос. Теоретически, как и модули питона, 
>> такие
>> > > библиотеки надо проверять с запрелоаденным libpython.
>> > > 2) Если ими пользуются только некие программы, слинкованные с
>> > > libpython, то линковку лучше оставить.
>> > > 3) Если ми пользуются и модули питона, и некие программы, 
>> слинкованные
>> > > с libpython, то случай тяжёлый, проблемы (теоретически) возможны 
>> и при
>> > > линковке, и при её отсутствии.
>> >
>> > С этими библиотеками никто не линкуется.
>>
>> Каким образом тогда эти библиотеки предполагается использовать?
>
> Сказанное выше, о том, что никто не линкуется с этими библиотеками,
> следует понимать так, что никто не линкуется с этими библиотеками 
> кроме
> питон-модулей в самих python-module-pygobject*. Т.е _сторонние_
> питон-модули и программы используют модули из 
> python-module-pygobject*,
> слинкованные с этими библиотеками.

Если с ними линкуются только модули питона, то с libpython их линковать 
не стоит, надо это как-то объяснить verify-elf.

Re: [devel] Rebuild to remove redundant libpython2.7 dependency

[Dmitry V. Levin]

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

On Fri, Apr 13, 2012 at 06:59:17PM +0400, Vitaly Kuznetsov wrote:
> On Fri, 13 Apr 2012 18:39:19 +0400, Yuri N. Sedunov wrote:
> >В Птн, 13/04/2012 в 16:18 +0400, Dmitry V. Levin пишет:
> >>On Fri, Apr 13, 2012 at 03:32:25PM +0400, Yuri N. Sedunov wrote:
[...]
> >>> С этими библиотеками никто не 
> >>линкуется.
> >>
> >>Каким образом тогда эти библиотеки 
> >>предполагается использовать?
> >
> >Сказанное выше, о том, что никто не 
> >линкуется с этими библиотеками,
> >следует понимать так, что никто не 
> >линкуется с этими библиотеками кроме
> >питон-модулей в самих python-module-pygobject*. Т.е 
> >_сторонние_
> >питон-модули и программы используют 
> >модули из python-module-pygobject*,
> >слинкованные с этими библиотеками.
> 
> Если с ними линкуются только модули 
> питона, то с libpython их линковать не стоит, 
> надо это как-то объяснить verify-elf.

Интерфейс объяснить verify-elf'у, что такие-то файлы вполне легально могут
быть не слинкованы с -lpython, никто еще не придумал.

Известен хак, который, наверное, можно использовать, пока нет нормального
интерфейса - добавить
export LD_PRELOAD=%_libdir/libpython%__python_version.so
в самом конце секции %install.


-- 
ldv

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

Re: [devel] Rebuild to remove redundant libpython2.7 dependency

[REAL]

14.04.2012 00:02, Dmitry V. Levin пишет:
> Интерфейс объяснить verify-elf'у, что такие-то файлы вполне легально могут
> быть не слинкованы с -lpython, никто еще не придумал.
>
> Известен хак, который, наверное, можно использовать, пока нет нормального
> интерфейса - добавить
> export LD_PRELOAD=%_libdir/libpython%__python_version.so
> в самом конце секции %install.

просьба вернуть обратно линковку с libpython*, потому что сломавшихся 
при сборке пакетов как-то подозрительно много. да вот, первое попавшееся:

checking consistency of all components of python development 
environment... no
configure: error:
   Could not link test program to Python. Maybe the main Python 
library has been
   installed in some non-standard library path. If so, pass it to 
configure,
   via the LDFLAGS environment variable.
   Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
 
============================================================================
    ERROR!
    You probably have to install the development version of the Python 
package
    for your distribution.  The exact name of this package varies 
among them.
 
============================================================================

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Rebuild to remove redundant libpython2.7 dependency

[Michael Shigorin]

On Sat, Apr 14, 2012 at 04:17:56PM +0700, REAL wrote:
> просьба вернуть обратно линковку с libpython*, потому что
> сломавшихся при сборке пакетов как-то подозрительно много.

А стоило ли вообще затевать переезд, если просадка на x86_64
незначительная и гонять на скорость приложения в байткоде на
i586 смысла изначально не было? (понятно, что унаследованные
оборудование/окружения жалко, но тогда осмысленно собираться
не под generic i586, а под i686 или i486, как ранее выясняли
насчёт эффективности и пригодности таких оптимизаций)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Rebuild to remove redundant libpython2.7 dependency

[REAL]

14.04.2012 16:32, Michael Shigorin пишет:
> On Sat, Apr 14, 2012 at 04:17:56PM +0700, REAL wrote:
>> просьба вернуть обратно линковку с libpython*, потому что
>> сломавшихся при сборке пакетов как-то подозрительно много.
>
> А стоило ли вообще затевать переезд

какой переезд?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Rebuild to remove redundant libpython2.7 dependency

[Michael Shigorin]

On Sat, Apr 14, 2012 at 05:43:34PM +0700, REAL wrote:
> >>просьба вернуть обратно линковку с libpython*, потому что
> >>сломавшихся при сборке пакетов как-то подозрительно много.
> >А стоило ли вообще затевать переезд
> какой переезд?

На статический libpython в интерпретаторе.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Rebuild to remove redundant libpython2.7 dependency

[Ivan A. Melnikov]

On Sat, 14 Apr 2012 16:17:56 +0700
REAL <real@kemsu.ru> wrote:

> 14.04.2012 00:02, Dmitry V. Levin пишет:
> > Интерфейс объяснить verify-elf'у, что такие-то файлы вполне
> > легально могут быть не слинкованы с -lpython, никто еще не придумал.
> >
> > Известен хак, который, наверное, можно использовать, пока нет
> > нормального интерфейса - добавить
> > export LD_PRELOAD=%_libdir/libpython%__python_version.so
> > в самом конце секции %install.
> 
> просьба вернуть обратно линковку с libpython*, потому что сломавшихся 
> при сборке пакетов как-то подозрительно много. да вот, первое
> попавшееся:
> 
> checking consistency of all components of python development 
> environment... no
> configure: error:
>    Could not link test program to Python. Maybe the main Python 
> library has been
>    installed in some non-standard library path. If so, pass it to 
> configure,
>    via the LDFLAGS environment variable.
>    Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
>  
> ============================================================================
>     ERROR!
>     You probably have to install the development version of the
> Python package
>     for your distribution.  The exact name of this package varies 
> among them.
>  
> ============================================================================
> 

Это больше похоже не на проблему недолинковки, а на косяк
auto{tools,make,hell} или запаковки питона. По неясным никому причинам
оно добавляет к командной строке компилятора
-L/usr/lib64/python2.7/config, в результате чего -lpython2.7 находит
не /usr/lib64/libpython2.7.so,
а /usr/lib64/python2.7/config/libpython2.7.a, которой нехватает кучи
символов из -lm. Сама по себе попытка слинковаться со статической
libpython в данном случае кажется ошибкой.

Смотрел на примере ldns.

-- 
WBR,
Ivan A. Melnikov

Re: [devel] Rebuild to remove redundant libpython2.7 dependency

[REAL]

14.04.2012 18:13, Ivan A. Melnikov пишет:
> Это больше похоже не на проблему недолинковки, а на косяк
> auto{tools,make,hell} или запаковки питона. По неясным никому причинам
> оно добавляет к командной строке компилятора
> -L/usr/lib64/python2.7/config, в результате чего -lpython2.7 находит
> не /usr/lib64/libpython2.7.so,
> а /usr/lib64/python2.7/config/libpython2.7.a,

какого лешего этот файл делает в python-base, хотел бы я знать...

> Смотрел на примере ldns.

я конкретно пока никуда не смотрел, просто увидел целую кучу сломанных 
сборок с руганью на питон.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

[devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Ivan A. Melnikov]

On Sat, 14 Apr 2012 18:55:27 +0700
REAL <real@kemsu.ru> wrote:

> 14.04.2012 18:13, Ivan A. Melnikov пишет:
> > Это больше похоже не на проблему недолинковки, а на косяк
> > auto{tools,make,hell} или запаковки питона. По неясным никому
> > причинам оно добавляет к командной строке компилятора
> > -L/usr/lib64/python2.7/config, в результате чего -lpython2.7 находит
> > не /usr/lib64/libpython2.7.so,
> > а /usr/lib64/python2.7/config/libpython2.7.a,
> 
> какого лешего этот файл делает в python-base, хотел бы я знать...
> 

Ошибка запаковки при переезде на статическую сборку python. По идее,
там вместо неё должен лежать симлинк libpython2.7.so
на ../../libpython2.7.so.

2 vitty@: вешать?

-- 
WBR,
Ivan A. Melnikov

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Vitaly Kuznetsov]

On Sun, 15 Apr 2012 08:58:15 +0400, Ivan A. Melnikov wrote:
> On Sat, 14 Apr 2012 18:55:27 +0700
> REAL <real@kemsu.ru> wrote:
>
>> 14.04.2012 18:13, Ivan A. Melnikov пишет:
>> > Это больше похоже не на проблему недолинковки, а на косяк
>> > auto{tools,make,hell} или запаковки питона. По неясным никому
>> > причинам оно добавляет к командной строке компилятора
>> > -L/usr/lib64/python2.7/config, в результате чего -lpython2.7 
>> находит
>> > не /usr/lib64/libpython2.7.so,
>> > а /usr/lib64/python2.7/config/libpython2.7.a,
>>
>> какого лешего этот файл делает в python-base, хотел бы я знать...
>>
>
> Ошибка запаковки при переезде на статическую сборку python. По идее,
> там вместо неё должен лежать симлинк libpython2.7.so
> на ../../libpython2.7.so.
>
> 2 vitty@: вешать?

Да, повесьте, пожалуйста, завтра исправлю.

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Dmitry V. Levin]

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

On Sun, Apr 15, 2012 at 07:22:48PM +0400, Vitaly Kuznetsov wrote:
> On Sun, 15 Apr 2012 08:58:15 +0400, Ivan A. Melnikov wrote:
> >On Sat, 14 Apr 2012 18:55:27 +0700
> >REAL <real@kemsu.ru> wrote:
> >
> >>14.04.2012 18:13, Ivan A. Melnikov пишет:
> >>> Это больше похоже не на проблему 
> >>недолинковки, а на косяк
> >>> auto{tools,make,hell} или запаковки питона. По 
> >>неясным никому
> >>> причинам оно добавляет к командной 
> >>строке компилятора
> >>> -L/usr/lib64/python2.7/config, в результате чего 
> >>-lpython2.7 находит
> >>> не /usr/lib64/libpython2.7.so,
> >>> а /usr/lib64/python2.7/config/libpython2.7.a,
> >>
> >>какого лешего этот файл делает в python-base, 
> >>хотел бы я знать...
> >>
> >
> >Ошибка запаковки при переезде на 
> >статическую сборку python. По идее,
> >там вместо неё должен лежать симлинк 
> >libpython2.7.so
> >на ../../libpython2.7.so.
> >
> >2 vitty@: вешать?
> 
> Да, повесьте, пожалуйста, завтра исправлю.

Пожарная бригада уже выехала и все потушила. :)


-- 
ldv

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

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Yuri N. Sedunov]

В Вск, 15/04/2012 в 19:22 +0400, Vitaly Kuznetsov пишет:
> On Sun, 15 Apr 2012 08:58:15 +0400, Ivan A. Melnikov wrote:
> > On Sat, 14 Apr 2012 18:55:27 +0700
> > REAL <real@kemsu.ru> wrote:
> >
> >> 14.04.2012 18:13, Ivan A. Melnikov пишет:
> >> > Это больше похоже не на проблему недолинковки, а на косяк
> >> > auto{tools,make,hell} или запаковки питона. По неясным никому
> >> > причинам оно добавляет к командной строке компилятора
> >> > -L/usr/lib64/python2.7/config, в результате чего -lpython2.7 
> >> находит
> >> > не /usr/lib64/libpython2.7.so,
> >> > а /usr/lib64/python2.7/config/libpython2.7.a,
> >>
> >> какого лешего этот файл делает в python-base, хотел бы я знать...
> >>
> >
> > Ошибка запаковки при переезде на статическую сборку python. По идее,
> > там вместо неё должен лежать симлинк libpython2.7.so
> > на ../../libpython2.7.so.
> >
> > 2 vitty@: вешать?
> 
> Да, повесьте, пожалуйста, завтра исправлю.


Зачем по-вашему нужен этот симлинк?

-- 
Yuri N. Sedunov

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Dmitry V. Levin]

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

On Sun, Apr 15, 2012 at 07:52:57PM +0400, Yuri N. Sedunov wrote:
> В Вск, 15/04/2012 в 19:22 +0400, Vitaly Kuznetsov пишет:
> > On Sun, 15 Apr 2012 08:58:15 +0400, Ivan A. Melnikov wrote:
> > > On Sat, 14 Apr 2012 18:55:27 +0700, REAL wrote:
> > >
> > >> 14.04.2012 18:13, Ivan A. Melnikov пишет:
> > >> > Это больше похоже не на проблему недолинковки, а на косяк
> > >> > auto{tools,make,hell} или запаковки питона. По неясным никому
> > >> > причинам оно добавляет к командной строке компилятора
> > >> > -L/usr/lib64/python2.7/config, в результате чего -lpython2.7 
> > >> находит
> > >> > не /usr/lib64/libpython2.7.so,
> > >> > а /usr/lib64/python2.7/config/libpython2.7.a,
> > >>
> > >> какого лешего этот файл делает в python-base, хотел бы я знать...
> > >>
> > >
> > > Ошибка запаковки при переезде на статическую сборку python. По идее,
> > > там вместо неё должен лежать симлинк libpython2.7.so
> > > на ../../libpython2.7.so.
> > >
> > > 2 vitty@: вешать?
> > 
> > Да, повесьте, пожалуйста, завтра исправлю.
> 
> Зачем по-вашему нужен этот симлинк?

Там и -L/usr/lib64/python2.7/config не нужен.  Но когда в
/usr/lib64/python2.7/config нет библиотек, от этого -L хотя бы вреда нет.


-- 
ldv

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

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Yuri N. Sedunov]

В Вск, 15/04/2012 в 20:07 +0400, Dmitry V. Levin пишет:
> On Sun, Apr 15, 2012 at 07:52:57PM +0400, Yuri N. Sedunov wrote:
> > В Вск, 15/04/2012 в 19:22 +0400, Vitaly Kuznetsov пишет:
> > > On Sun, 15 Apr 2012 08:58:15 +0400, Ivan A. Melnikov wrote:
> > > > On Sat, 14 Apr 2012 18:55:27 +0700, REAL wrote:
> > > >
> > > >> 14.04.2012 18:13, Ivan A. Melnikov пишет:
> > > >> > Это больше похоже не на проблему недолинковки, а на косяк
> > > >> > auto{tools,make,hell} или запаковки питона. По неясным никому
> > > >> > причинам оно добавляет к командной строке компилятора
> > > >> > -L/usr/lib64/python2.7/config, в результате чего -lpython2.7 
> > > >> находит
> > > >> > не /usr/lib64/libpython2.7.so,
> > > >> > а /usr/lib64/python2.7/config/libpython2.7.a,
> > > >>
> > > >> какого лешего этот файл делает в python-base, хотел бы я знать...
> > > >>
> > > >
> > > > Ошибка запаковки при переезде на статическую сборку python. По идее,
> > > > там вместо неё должен лежать симлинк libpython2.7.so
> > > > на ../../libpython2.7.so.
> > > >
> > > > 2 vitty@: вешать?
> > > 
> > > Да, повесьте, пожалуйста, завтра исправлю.
> > 
> > Зачем по-вашему нужен этот симлинк?
> 
> Там и -L/usr/lib64/python2.7/config не нужен.  Но когда в
> /usr/lib64/python2.7/config нет библиотек, от этого -L хотя бы вреда нет.
> 
> 

И здесь надо исправить.
$ python-config --ldflags
-L/usr/lib/python2.7/config -lpthread -ldl -lutil -lm -lpython2.7
-Xlinker -export-dynamic


-- 
Yuri N. Sedunov

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Vitaly Kuznetsov]

On Sun, 15 Apr 2012 20:13:37 +0400, Yuri N. Sedunov wrote:
> В Вск, 15/04/2012 в 20:07 +0400, Dmitry V. Levin пишет:
>> > > > Ошибка запаковки при переезде на статическую сборку python. По 
>> идее,
>> > > > там вместо неё должен лежать симлинк libpython2.7.so
>> > > > на ../../libpython2.7.so.
>> > > >
>> > > > 2 vitty@: вешать?
>> > >
>> > > Да, повесьте, пожалуйста, завтра исправлю.
>> >
>> > Зачем по-вашему нужен этот симлинк?
>>
>> Там и -L/usr/lib64/python2.7/config не нужен.  Но когда в
>> /usr/lib64/python2.7/config нет библиотек, от этого -L хотя бы вреда 
>> нет.
>>
>
> И здесь надо исправить.
> $ python-config --ldflags
> -L/usr/lib/python2.7/config -lpthread -ldl -lutil -lm -lpython2.7
> -Xlinker -export-dynamic

Не нравится -l или -L? Или обе? :)

Захакать, конечно, можно, но от этого могут сломаться те, кому 
действительно надо линковаться с libpython. В debian, чей подход к 
сборке python мы в том или ином виде пытаемся повторить сейчас сделано 
так:

в /usr/lib{,64}/python2.x/config/ лежат:
файлы пакета python-dev:
libpython2.x.a
libpython2.x-pic.a
файл пакета libpython:
libpython2.x.so -> ../../libpython2.x.so.1

python-config --ldflags:
-L/usr/lib/python2.x/config -lpthread -ldl -lutil -lm -lpython2.x

В python-config логика следующая:
         libs = getvar('LIBS').split() + getvar('SYSLIBS').split()
         libs.append('-lpython'+pyver)
         # add the prefix/lib/pythonX.Y/config dir, but only if there is 
no
         # shared library in prefix/lib/.
         if opt == '--ldflags':
             if not getvar('Py_ENABLE_SHARED'):
                 libs.insert(0, '-L' + getvar('LIBPL'))
             libs.extend(getvar('LINKFORSHARED').split())
         print ' '.join(libs)

т.е. -lpython2.x добавляется всегда, -L/usr/lib{,64}/python2.x/config 
добавляется в случае статической линковки интерпретатора с libpython. У 
нас, насколько я понимаю, пользователей статической libpython2.x.a нет, 
не стоит их и заводить. Стоит, на мой взгляд, красоты ради отучить 
python-config выводить -L/usr/lib{,64}/python2.x/config, -lpython2.x же 
лучше оставить. Или я не прав?

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[REAL]

16.04.2012 12:01, Vitaly Kuznetsov пишет:
> т.е. -lpython2.x добавляется всегда, -L/usr/lib{,64}/python2.x/config
> добавляется в случае статической линковки интерпретатора с libpython.
> У нас, насколько я понимаю, пользователей статической libpython2.x.a
> нет, не стоит их и заводить. Стоит, на мой взгляд, красоты ради
> отучить python-config выводить -L/usr/lib{,64}/python2.x/config,
> -lpython2.x же лучше оставить. Или я не прав?

Не знаю, как другим, а мне главное - libpython2.x.a пусть уйдёт 
куда-нибудь туда, откуда его надо специально выковыривать 
(libpython-devel-static, например), чтоб не лез под ноги.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Vitaly Kuznetsov]

On Mon, 16 Apr 2012 12:11:11 +0700, REAL wrote:
> 16.04.2012 12:01, Vitaly Kuznetsov пишет:
>> т.е. -lpython2.x добавляется всегда, 
>> -L/usr/lib{,64}/python2.x/config
>> добавляется в случае статической линковки интерпретатора с 
>> libpython.
>> У нас, насколько я понимаю, пользователей статической libpython2.x.a
>> нет, не стоит их и заводить. Стоит, на мой взгляд, красоты ради
>> отучить python-config выводить -L/usr/lib{,64}/python2.x/config,
>> -lpython2.x же лучше оставить. Или я не прав?
>
> Не знаю, как другим, а мне главное - libpython2.x.a пусть уйдёт
> куда-нибудь туда, откуда его надо специально выковыривать
> (libpython-devel-static, например), чтоб не лез под ноги.

Пока вообще нет смысла паковать libpython2.x.a

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Yuri N. Sedunov]

В Пнд, 16/04/2012 в 09:01 +0400, Vitaly Kuznetsov пишет:
> On Sun, 15 Apr 2012 20:13:37 +0400, Yuri N. Sedunov wrote:
> > В Вск, 15/04/2012 в 20:07 +0400, Dmitry V. Levin пишет:
> >> > > > Ошибка запаковки при переезде на статическую сборку python. По 
> >> идее,
> >> > > > там вместо неё должен лежать симлинк libpython2.7.so
> >> > > > на ../../libpython2.7.so.
> >> > > >
> >> > > > 2 vitty@: вешать?
> >> > >
> >> > > Да, повесьте, пожалуйста, завтра исправлю.
> >> >
> >> > Зачем по-вашему нужен этот симлинк?
> >>
> >> Там и -L/usr/lib64/python2.7/config не нужен.  Но когда в
> >> /usr/lib64/python2.7/config нет библиотек, от этого -L хотя бы вреда 
> >> нет.
> >>
> >
> > И здесь надо исправить.
> > $ python-config --ldflags
> > -L/usr/lib/python2.7/config -lpthread -ldl -lutil -lm -lpython2.7
> > -Xlinker -export-dynamic
> 
> Не нравится -l или -L? Или обе? :)
> 
> Захакать, конечно, можно, но от этого могут сломаться те, кому 
> действительно надо линковаться с libpython. В debian, чей подход к 
> сборке python мы в том или ином виде пытаемся повторить сейчас сделано 
> так:
> 
> в /usr/lib{,64}/python2.x/config/ лежат:
> файлы пакета python-dev:
> libpython2.x.a
> libpython2.x-pic.a
> файл пакета libpython:
> libpython2.x.so -> ../../libpython2.x.so.1
> 
> python-config --ldflags:
> -L/usr/lib/python2.x/config -lpthread -ldl -lutil -lm -lpython2.x
> 
> В python-config логика следующая:
>          libs = getvar('LIBS').split() + getvar('SYSLIBS').split()
>          libs.append('-lpython'+pyver)
>          # add the prefix/lib/pythonX.Y/config dir, but only if there is 
> no
>          # shared library in prefix/lib/.
>          if opt == '--ldflags':
>              if not getvar('Py_ENABLE_SHARED'):
>                  libs.insert(0, '-L' + getvar('LIBPL'))
>              libs.extend(getvar('LINKFORSHARED').split())
>          print ' '.join(libs)
> 
> т.е. -lpython2.x добавляется всегда, -L/usr/lib{,64}/python2.x/config 
> добавляется в случае статической линковки интерпретатора с libpython. У 
> нас, насколько я понимаю, пользователей статической libpython2.x.a нет, 
> не стоит их и заводить. Стоит, на мой взгляд, красоты ради отучить 
> python-config выводить -L/usr/lib{,64}/python2.x/config, -lpython2.x же 
> лучше оставить. Или я не прав?

По-моему, никакой пользы кроме вреда от наличия -lpython2.x в выводе
python-config нет, если уж мы решили не линковать питон-модули с
libpython.

Кому, по-вашему, может понадобиться линковаться с libpython?



-- 
Yuri N. Sedunov

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[REAL]

16.04.2012 12:18, Yuri N. Sedunov пишет:
> Кому, по-вашему, может понадобиться линковаться с libpython?

Вот пример:
 > ldd /usr/lib/libvtkPythonCore.so.5.8.0
         linux-gate.so.1 =>  (0xb777c000)
         libvtkCommon.so.5.8 => /usr/lib/libvtkCommon.so.5.8 (0xb735c000)
         libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0xb71c7000)
         ^^^^^^^^^^^^^^^^^^^
         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb70db000)
         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb70be000)
         libc.so.6 => /lib/libc.so.6 (0xb6f5a000)
         libvtksys.so.5.8 => /usr/lib/libvtksys.so.5.8 (0xb6f20000)
         libpthread.so.0 => /lib/libpthread.so.0 (0xb6f06000)
         libm.so.6 => /lib/libm.so.6 (0xb6edc000)
         libdl.so.2 => /lib/libdl.so.2 (0xb6ed7000)
         libutil.so.1 => /lib/libutil.so.1 (0xb6ed2000)
         /lib/ld-linux.so.2 (0xb777d000)


-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Yuri N. Sedunov]

В Пнд, 16/04/2012 в 12:40 +0700, REAL пишет:
> 16.04.2012 12:18, Yuri N. Sedunov пишет:
> > Кому, по-вашему, может понадобиться линковаться с libpython?
> 
> Вот пример:
>  > ldd /usr/lib/libvtkPythonCore.so.5.8.0
>          linux-gate.so.1 =>  (0xb777c000)
>          libvtkCommon.so.5.8 => /usr/lib/libvtkCommon.so.5.8 (0xb735c000)
>          libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0xb71c7000)
>          ^^^^^^^^^^^^^^^^^^^
>          libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb70db000)
>          libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb70be000)
>          libc.so.6 => /lib/libc.so.6 (0xb6f5a000)
>          libvtksys.so.5.8 => /usr/lib/libvtksys.so.5.8 (0xb6f20000)
>          libpthread.so.0 => /lib/libpthread.so.0 (0xb6f06000)
>          libm.so.6 => /lib/libm.so.6 (0xb6edc000)
>          libdl.so.2 => /lib/libdl.so.2 (0xb6ed7000)
>          libutil.so.1 => /lib/libutil.so.1 (0xb6ed2000)
>          /lib/ld-linux.so.2 (0xb777d000)
> 

Что будет, если эта библиотека будет недолинкована с libpython, как,
например?

$ ldd -r /usr/lib/libpyglib-2.0-python.so.0 2>&1|grep undefined|wc -l
38
[aris@aris_dell SPECS]$ ldd -r /usr/lib/libpyglib-gi-2.0-python.so.0
2>&1|grep undefined|wc -l
38



-- 
Yuri N. Sedunov

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[REAL]

16.04.2012 12:54, Yuri N. Sedunov пишет:
>> Вот пример:
>>   >  ldd /usr/lib/libvtkPythonCore.so.5.8.0
[...]
>>           libpython2.7.so.1.0 =>  /usr/lib/libpython2.7.so.1.0 (0xb71c7000)
>>           ^^^^^^^^^^^^^^^^^^^
[...]
> Что будет, если эта библиотека будет недолинкована с libpython

Можно задать вопрос иначе:

Что будет, если библиотека будет недолинкована с какой-либо другой 
библиотекой? Например, libz.so или libm.so. Зачем вообще тогда 
проверяется линковка библиотек, если допускать, что недолинковка - это 
нестрашно?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Yuri N. Sedunov]

В Пнд, 16/04/2012 в 12:58 +0700, REAL пишет:
> 16.04.2012 12:54, Yuri N. Sedunov пишет:
> >> Вот пример:
> >>   >  ldd /usr/lib/libvtkPythonCore.so.5.8.0
> [...]
> >>           libpython2.7.so.1.0 =>  /usr/lib/libpython2.7.so.1.0 (0xb71c7000)
> >>           ^^^^^^^^^^^^^^^^^^^
> [...]
> > Что будет, если эта библиотека будет недолинкована с libpython
> 
> Можно задать вопрос иначе:
> 
> Что будет, если библиотека будет недолинкована с какой-либо другой 
> библиотекой? Например, libz.so или libm.so. Зачем вообще тогда 
> проверяется линковка библиотек, если допускать, что недолинковка - это 
> нестрашно?
> 

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

-- 
Yuri N. Sedunov

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Vitaly Kuznetsov]

On Mon, 16 Apr 2012 12:58:16 +0700, REAL wrote:
> 16.04.2012 12:54, Yuri N. Sedunov пишет:
>>> Вот пример:
>>>   >  ldd /usr/lib/libvtkPythonCore.so.5.8.0
> [...]
>>>           libpython2.7.so.1.0 =>  /usr/lib/libpython2.7.so.1.0 
>>> (0xb71c7000)
>>>           ^^^^^^^^^^^^^^^^^^^
> [...]
>> Что будет, если эта библиотека будет недолинкована с libpython
>
> Можно задать вопрос иначе:
>
> Что будет, если библиотека будет недолинкована с какой-либо другой
> библиотекой? Например, libz.so или libm.so. Зачем вообще тогда
> проверяется линковка библиотек, если допускать, что недолинковка - 
> это
> нестрашно?

Модули питона загружает та или иная реализация питона (/usr/bin/python 
или libpython), варианта, когда в адресном пространстве не окажется 
какой-нибудь реализации нет. Это как-бы плагины к реализации питона. Для 
libz.so ситуация другая, для неё нет альтернативной реализации (обычно 
:), её должен кто-то грузить. Линковка вам это гарантирует.

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Vitaly Kuznetsov]

On Mon, 16 Apr 2012 09:54:26 +0400, Yuri N. Sedunov wrote:
> В Пнд, 16/04/2012 в 12:40 +0700, REAL пишет:
>> 16.04.2012 12:18, Yuri N. Sedunov пишет:
>> > Кому, по-вашему, может понадобиться линковаться с libpython?
>>
>> Вот пример:
>>  > ldd /usr/lib/libvtkPythonCore.so.5.8.0
>>          linux-gate.so.1 =>  (0xb777c000)
>>          libvtkCommon.so.5.8 => /usr/lib/libvtkCommon.so.5.8 
>> (0xb735c000)
>>          libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 
>> (0xb71c7000)
>>          ^^^^^^^^^^^^^^^^^^^
>>          libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb70db000)
>>          libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb70be000)
>>          libc.so.6 => /lib/libc.so.6 (0xb6f5a000)
>>          libvtksys.so.5.8 => /usr/lib/libvtksys.so.5.8 (0xb6f20000)
>>          libpthread.so.0 => /lib/libpthread.so.0 (0xb6f06000)
>>          libm.so.6 => /lib/libm.so.6 (0xb6edc000)
>>          libdl.so.2 => /lib/libdl.so.2 (0xb6ed7000)
>>          libutil.so.1 => /lib/libutil.so.1 (0xb6ed2000)
>>          /lib/ld-linux.so.2 (0xb777d000)
>>
>
> Что будет, если эта библиотека будет недолинкована с libpython, как,
> например?
>
> $ ldd -r /usr/lib/libpyglib-2.0-python.so.0 2>&1|grep undefined|wc -l
> 38
> [aris@aris_dell SPECS]$ ldd -r /usr/lib/libpyglib-gi-2.0-python.so.0
> 2>&1|grep undefined|wc -l
> 38

Если, как мы выясняли, это библиотеки для модулей питона -- то всё 
хорошо. С vtk, возможно, другая ситуация.

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Vitaly Kuznetsov]

On Mon, 16 Apr 2012 09:18:51 +0400, Yuri N. Sedunov wrote:
>
> По-моему, никакой пользы кроме вреда от наличия -lpython2.x в выводе
> python-config нет, если уж мы решили не линковать питон-модули с
> libpython.
>
> Кому, по-вашему, может понадобиться линковаться с libpython?

С libpython линкуются модули различных программы 
(bluefish,gimp,anjuta,virtualbox,...), и там эта линковка действительно 
нужна. Они-то и должны использовать python-config.

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Yuri N. Sedunov]

В Пнд, 16/04/2012 в 09:58 +0400, Vitaly Kuznetsov пишет:
> On Mon, 16 Apr 2012 09:18:51 +0400, Yuri N. Sedunov wrote:
> >
> > По-моему, никакой пользы кроме вреда от наличия -lpython2.x в выводе
> > python-config нет, если уж мы решили не линковать питон-модули с
> > libpython.
> >
> > Кому, по-вашему, может понадобиться линковаться с libpython?
> 
> С libpython линкуются модули различных программы 
> (bluefish,gimp,anjuta,virtualbox,...), и там эта линковка действительно 
> нужна. Они-то и должны использовать python-config.

Действительно ли нужна линковка с libpython этим модулям?

-- 
Yuri N. Sedunov

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Vitaly Kuznetsov]

On Mon, 16 Apr 2012 10:02:25 +0400, Yuri N. Sedunov wrote:
> В Пнд, 16/04/2012 в 09:58 +0400, Vitaly Kuznetsov пишет:
>> On Mon, 16 Apr 2012 09:18:51 +0400, Yuri N. Sedunov wrote:
>> >
>> > По-моему, никакой пользы кроме вреда от наличия -lpython2.x в 
>> выводе
>> > python-config нет, если уж мы решили не линковать питон-модули с
>> > libpython.
>> >
>> > Кому, по-вашему, может понадобиться линковаться с libpython?
>>
>> С libpython линкуются модули различных программы
>> (bluefish,gimp,anjuta,virtualbox,...), и там эта линковка 
>> действительно
>> нужна. Они-то и должны использовать python-config.
>
> Действительно ли нужна линковка с libpython этим модулям?

Насколько я понимаю, эти программы не вызывают интерпретатор 
(/usr/bin/python), они используют именно libpython-овскую реализацию 
питона. Если линковки не будет, то никто не загрузит никакую реализацию 
питона.

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Yuri N. Sedunov]

В Пнд, 16/04/2012 в 10:07 +0400, Vitaly Kuznetsov пишет:
> On Mon, 16 Apr 2012 10:02:25 +0400, Yuri N. Sedunov wrote:
> > В Пнд, 16/04/2012 в 09:58 +0400, Vitaly Kuznetsov пишет:
> >> On Mon, 16 Apr 2012 09:18:51 +0400, Yuri N. Sedunov wrote:
> >> >
> >> > По-моему, никакой пользы кроме вреда от наличия -lpython2.x в 
> >> выводе
> >> > python-config нет, если уж мы решили не линковать питон-модули с
> >> > libpython.
> >> >
> >> > Кому, по-вашему, может понадобиться линковаться с libpython?
> >>
> >> С libpython линкуются модули различных программы
> >> (bluefish,gimp,anjuta,virtualbox,...), и там эта линковка 
> >> действительно
> >> нужна. Они-то и должны использовать python-config.
> >
> > Действительно ли нужна линковка с libpython этим модулям?
> 
> Насколько я понимаю, эти программы не вызывают интерпретатор 
> (/usr/bin/python), они используют именно libpython-овскую реализацию 
> питона. Если линковки не будет, то никто не загрузит никакую реализацию 
> питона.

gimp, например, вызывает. Найдите, плиз, исключение.

-- 
Yuri N. Sedunov

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Vitaly Kuznetsov]

On Mon, 16 Apr 2012 10:14:48 +0400, Yuri N. Sedunov wrote:
>>
>> Насколько я понимаю, эти программы не вызывают интерпретатор
>> (/usr/bin/python), они используют именно libpython-овскую реализацию
>> питона. Если линковки не будет, то никто не загрузит никакую 
>> реализацию
>> питона.
>
> gimp, например, вызывает. Найдите, плиз, исключение.

Ok, с небольшим упрощением тест следующий:

1) Берём программу unbound.
2) Заменяем в системе libpython2.7.so на пустую библиотеку
3) Добавляем в конфиг unbound скрипт на питоне
4) Запускаем программу unbound:

# /etc/init.d/unbound restart
Stopping unbound service:                                               
                                                                         
               [ DONE ]
Update root anchor:unbound-anchor: symbol lookup error: 
/usr/lib64/libunbound.so.2: undefined symbol: PyObject_GenericGetAttr
                                                                         
                                                                         
             [FAILED]

Тест корректен?

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Yuri N. Sedunov]

В Пнд, 16/04/2012 в 10:54 +0400, Vitaly Kuznetsov пишет:
> On Mon, 16 Apr 2012 10:14:48 +0400, Yuri N. Sedunov wrote:
> >>
> >> Насколько я понимаю, эти программы не вызывают интерпретатор
> >> (/usr/bin/python), они используют именно libpython-овскую реализацию
> >> питона. Если линковки не будет, то никто не загрузит никакую 
> >> реализацию
> >> питона.
> >
> > gimp, например, вызывает. Найдите, плиз, исключение.
> 
> Ok, с небольшим упрощением тест следующий:
> 
    1) Берём программу unbound.
1A) пересобираем undound, чтоб убрать redundant libpython2.7 dependency

> 2) Заменяем в системе libpython2.7.so на пустую библиотеку
> 3) Добавляем в конфиг unbound скрипт на питоне
> 4) Запускаем программу unbound:
> 
> # /etc/init.d/unbound restart
> Stopping unbound service:                                               
>                                                                          
>                [ DONE ]
> Update root anchor:unbound-anchor: symbol lookup error: 
> /usr/lib64/libunbound.so.2: undefined symbol: PyObject_GenericGetAttr
>                                                                          
>                                                                          
>              [FAILED]
> 
> Тест корректен?
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
Yuri N. Sedunov

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Vitaly Kuznetsov]

On Mon, 16 Apr 2012 11:13:39 +0400, Yuri N. Sedunov wrote:
> В Пнд, 16/04/2012 в 10:54 +0400, Vitaly Kuznetsov пишет:
>> On Mon, 16 Apr 2012 10:14:48 +0400, Yuri N. Sedunov wrote:
>> >>
>> >> Насколько я понимаю, эти программы не вызывают интерпретатор
>> >> (/usr/bin/python), они используют именно libpython-овскую 
>> реализацию
>> >> питона. Если линковки не будет, то никто не загрузит никакую
>> >> реализацию
>> >> питона.
>> >
>> > gimp, например, вызывает. Найдите, плиз, исключение.
>>
>> Ok, с небольшим упрощением тест следующий:
>>
>     1) Берём программу unbound.
> 1A) пересобираем undound, чтоб убрать redundant libpython2.7 
> dependency
>

... и в процессе сборки по куче undefined references выясняем, что она 
совсем не redundant.

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Yuri N. Sedunov]

В Пнд, 16/04/2012 в 11:25 +0400, Vitaly Kuznetsov пишет:
> On Mon, 16 Apr 2012 11:13:39 +0400, Yuri N. Sedunov wrote:
> > В Пнд, 16/04/2012 в 10:54 +0400, Vitaly Kuznetsov пишет:
> >> On Mon, 16 Apr 2012 10:14:48 +0400, Yuri N. Sedunov wrote:
> >> >>
> >> >> Насколько я понимаю, эти программы не вызывают интерпретатор
> >> >> (/usr/bin/python), они используют именно libpython-овскую 
> >> реализацию
> >> >> питона. Если линковки не будет, то никто не загрузит никакую
> >> >> реализацию
> >> >> питона.
> >> >
> >> > gimp, например, вызывает. Найдите, плиз, исключение.
> >>
> >> Ok, с небольшим упрощением тест следующий:
> >>
> >     1) Берём программу unbound.
> > 1A) пересобираем undound, чтоб убрать redundant libpython2.7 
> > dependency
> >
> 
> ... и в процессе сборки по куче undefined references выясняем, что она 
> совсем не redundant.

Ну, в pygobject'ах, казалось бы тоже.


-- 
Yuri N. Sedunov

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Vitaly Kuznetsov]

On Mon, 16 Apr 2012 11:28:26 +0400, Yuri N. Sedunov wrote:
> В Пнд, 16/04/2012 в 11:25 +0400, Vitaly Kuznetsov пишет:
>> On Mon, 16 Apr 2012 11:13:39 +0400, Yuri N. Sedunov wrote:
>> > В Пнд, 16/04/2012 в 10:54 +0400, Vitaly Kuznetsov пишет:
>> >> On Mon, 16 Apr 2012 10:14:48 +0400, Yuri N. Sedunov wrote:
>> >> >>
>> >> >> Насколько я понимаю, эти программы не вызывают интерпретатор
>> >> >> (/usr/bin/python), они используют именно libpython-овскую
>> >> реализацию
>> >> >> питона. Если линковки не будет, то никто не загрузит никакую
>> >> >> реализацию
>> >> >> питона.
>> >> >
>> >> > gimp, например, вызывает. Найдите, плиз, исключение.
>> >>
>> >> Ok, с небольшим упрощением тест следующий:
>> >>
>> >     1) Берём программу unbound.
>> > 1A) пересобираем undound, чтоб убрать redundant libpython2.7
>> > dependency
>> >
>>
>> ... и в процессе сборки по куче undefined references выясняем, что 
>> она
>> совсем не redundant.
>
> Ну, в pygobject'ах, казалось бы тоже.

...

По результатам обсуждения в Сизиф отправлен python-2.7.3-alt3, в 
котором python-config --ldflags выглядит так:
-lpthread -ldl -lutil -lm -Xlinker -export-dynamic

по результатам тестовой пересборки мы решим, насколько такое изменение 
корректно.

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Dmitry V. Levin]

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

On Mon, Apr 16, 2012 at 10:02:25AM +0400, Yuri N. Sedunov wrote:
> В Пнд, 16/04/2012 в 09:58 +0400, Vitaly Kuznetsov пишет:
> > On Mon, 16 Apr 2012 09:18:51 +0400, Yuri N. Sedunov wrote:
> > >
> > > По-моему, никакой пользы кроме вреда от наличия -lpython2.x в выводе
> > > python-config нет, если уж мы решили не линковать питон-модули с
> > > libpython.
> > >
> > > Кому, по-вашему, может понадобиться линковаться с libpython?
> > 
> > С libpython линкуются модули различных программы 
> > (bluefish,gimp,anjuta,virtualbox,...), и там эта линковка действительно 
> > нужна. Они-то и должны использовать python-config.
> 
> Действительно ли нужна линковка с libpython этим модулям?

Некоторым точно нужна.  Вот, например,
http://git.altlinux.org/gears/v/..git?p=vim.git;a=blob;f=src/if_python.c

Беда новой схемы упаковки питона в том, что привносится человеческий
фактор там, где раньше хватало простого линкера.  В одной и той же
ситуации один человек говорит, что линковать данный конкретный elf c
libpython не нужно, а другой - что необходимо.  И при этом один из них
обязательно ошибается.


-- 
ldv

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

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Ivan A. Melnikov]

On Mon, 16 Apr 2012 09:18:51 +0400
"Yuri N. Sedunov" <aris@altlinux.org> wrote:
> 
> Кому, по-вашему, может понадобиться линковаться с libpython?
> 

Любому приложению, встраивающиму (embedding) python, то есть самому
изображающему из себя интерпретатор питона. Характерный признак --
обращение к Py_Initialize{,Ex}.

-- 
WBR,
Ivan A. Melnikov

Re: [devel] /usr/lib64/python2.7/config/libpython2.7.a is WRONG

[Dmitry V. Levin]

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

On Mon, Apr 16, 2012 at 09:01:21AM +0400, Vitaly Kuznetsov wrote:
> On Sun, 15 Apr 2012 20:13:37 +0400, Yuri N. Sedunov wrote:
[...]
> >И здесь надо исправить.
> >$ python-config --ldflags
> >-L/usr/lib/python2.7/config -lpthread -ldl -lutil -lm -lpython2.7
> >-Xlinker -export-dynamic
> 
> Не нравится -l или -L? Или обе? :)

Тут много чего не нравится.
-L не нужен просто потому, что в /usr/lib/python2.7/config нет никаких
библиотек.
-lpthread -ldl -lutil -lm -lpython2.7 не нравится, потому что --ldflags
это не --libs.

Но это именно не нравится, эти лишние -L и -l хотя бы ничего не ломают.

> Захакать, конечно, можно, но от этого 
> могут сломаться те, кому действительно 
> надо линковаться с libpython. В debian, чей 
> подход к сборке python мы в том или ином виде 
> пытаемся повторить

Не понимаю, зачем мы пытаемся этот подход повторить.  Он, в отличие от
традиционного, будет постоянно создавать нам проблемы.

> в /usr/lib{,64}/python2.x/config/ лежат:
> файлы пакета python-dev:
> libpython2.x.a
> libpython2.x-pic.a
> файл пакета libpython:
> libpython2.x.so -> ../../libpython2.x.so.1

У нас всего этого нагромождения нет, и не надо.

> python-config --ldflags:
> -L/usr/lib/python2.x/config -lpthread -ldl -lutil -lm -lpython2.x
> 
> В python-config логика следующая:
>         libs = getvar('LIBS').split() + getvar('SYSLIBS').split()
>         libs.append('-lpython'+pyver)
>         # add the prefix/lib/pythonX.Y/config dir, but only if there is 
> no
>         # shared library in prefix/lib/.
>         if opt == '--ldflags':
>             if not getvar('Py_ENABLE_SHARED'):
>                 libs.insert(0, '-L' + getvar('LIBPL'))
>             libs.extend(getvar('LINKFORSHARED').split())
>         print ' '.join(libs)
> 
> т.е. -lpython2.x добавляется всегда, 
> -L/usr/lib{,64}/python2.x/config добавляется в случае 
> статической линковки интерпретатора с 
> libpython. У нас, насколько я понимаю, 
> пользователей статической libpython2.x.a нет, 

У нас есть python-devel-static, и его для потенциальных пользователей
libpython2.7.a вполне достаточно.


-- 
ldv

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

Re: [devel] Rebuild to remove redundant libpython2.7 dependency

[REAL]

13.04.2012 17:56, Vitaly Kuznetsov пишет:
> теоретическая необходимость их линковки с libpython
> зависит от того, кто этими библиотеками пользуется:
> 1) Если ими пользуются модули питона, то лучше не линковать из с
> libpython -- модуль может использоваться и под /usr/bin/python. Как
> это обойти в verify-elf - вопрос. Теоретически, как и модули питона,
> такие библиотеки надо проверять с запрелоаденным libpython.
> 2) Если ими пользуются только некие программы, слинкованные с
> libpython, то линковку лучше оставить.
> 3) Если ими пользуются и модули питона, и некие программы,
> слинкованные с libpython, то случай тяжёлый, проблемы (теоретически)
> возможны и при линковке, и при её отсутствии. Я бы посмотрел на то,
> как поступили в debian -- у них аналогичный нашему "распил питона".

не озвучен случай 4:

с libpython слинкована библиотека.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ