Re: [devel] E: incoming x86_64 reject: qscintilla2-2-alt1.20080103

Re: [devel] E: incoming x86_64 reject: qscintilla2-2-alt1.20080103

[Gennady Kovalev]

Ув. коллеги, прошу помощи. А то я тут пока не шибко бум-бум.

Инкоминг не берет библиотечку.

Вот есть куча таких ворнингов. 
> verify-elf: WARNING: ./usr/lib64/python2.4/site-packages/qsci.so: undefined 
symbol: _ZN12QsciLexerCSSC2EP7QObjectPKc

Это смертельно?

> verify-elf: ERROR: ./usr/lib64/python2.4/site-packages/PyQt4/Qsci.so: RPATH 
entry 
contains "/usr/src/RPM/BUILD": /usr/src/RPM/BUILD/qscintilla-2/Qt4:/usr/lib64

Что это, Бэримор?

Еще вопрос: как мне запускать hasher на своей машине, чтобы оно у меня тоже не 
собиралось. А то мой hasher писал ворнинги, error не было, и пакет сделал.


-- 
Gennady Kovalev, 
BIGUR, ALT Linux Team.

Re: [devel] E: incoming x86_64 reject: qscintilla2-2-alt1.20080103

[Gennady Kovalev]

В сообщении от Friday 04 January 2008 22:23:36 Gennady Kovalev написал(а):

> Вот есть куча таких ворнингов.
>
> > verify-elf: WARNING: ./usr/lib64/python2.4/site-packages/qsci.so:
> > undefined
>
> symbol: _ZN12QsciLexerCSSC2EP7QObjectPKc
>
> Это смертельно?

На этот вопрос я ответа не получил.


> > verify-elf: ERROR: ./usr/lib64/python2.4/site-packages/PyQt4/Qsci.so:
> > RPATH
>
> entry
> contains "/usr/src/RPM/BUILD":
> /usr/src/RPM/BUILD/qscintilla-2/Qt4:/usr/lib64
>
> Что это, Бэримор?

В момент сборки модуля для python я использовал путь к скомпилированной в этом 
же пакете библиотеке. Путь находился в сборочной среде.

pyqtconfig, когда ему configure.py добавлял путь для поиска библиотекиб 
автоматически пропихивал путь из сборочной среды в RPATH. Пропатчено.

Спасибо 

http://www.freesource.info/wiki/AltLinux/Sisyphus/devel/ProblemWithVerifyELFAndRPATH

за разъяснение, что такое RPATH.

> Еще вопрос: как мне запускать hasher на своей машине, чтобы оно у меня тоже
> не собиралось. А то мой hasher писал ворнинги, error не было, и пакет
> сделал.

Это оказывается пока работал над пакетом обновился python-module-PyQt4. 
Обновился, сборка у меня тоже упала.

-- 
Gennady Kovalev, 
BIGUR, ALT Linux Team.

Re: [devel] E: incoming x86_64 reject: qscintilla2-2-alt1.20080103

[Gennady Kovalev]

> > Вот есть куча таких ворнингов.
> >
> > > verify-elf: WARNING: ./usr/lib64/python2.4/site-packages/qsci.so:
> > > undefined
> >
> > symbol: _ZN12QsciLexerCSSC2EP7QObjectPKc
> >
> > Это смертельно?
>
> На этот вопрос я ответа не получил.

Я бы даже переформулировал бы вопрос. Пакет собирается и работает. Но с 
идеалогическнео точки знения, с точки зрения дистрибьютива смертельно или 
нет?

-- 
Gennady Kovalev, 
BIGUR, ALT Linux Team.

Re: [devel] E: incoming x86_64 reject: qscintilla2-2-alt1.20080103

[Dmitry V. Levin]

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

On Sat, Jan 05, 2008 at 05:48:01PM +0300, Gennady Kovalev wrote:
> > > Вот есть куча таких ворнингов.
> > >
> > > > verify-elf: WARNING: ./usr/lib64/python2.4/site-packages/qsci.so:
> > > > undefined
> > >
> > > symbol: _ZN12QsciLexerCSSC2EP7QObjectPKc
> > >
> > > Это смертельно?
> >
> > На этот вопрос я ответа не получил.
> 
> Я бы даже переформулировал бы вопрос. Пакет собирается и работает. Но с 
> идеалогическнео точки знения, с точки зрения дистрибьютива смертельно или 
> нет?

Ответ на вопрос зависит от того, где определён этот символ,
$ echo _ZN12QsciLexerCSSC2EP7QObjectPKc |c++filt 
QsciLexerCSS::QsciLexerCSS(QObject*, char const*)


-- 
ldv

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

Re: [devel] E: incoming x86_64 reject: qscintilla2-2-alt1.20080103

[Gennady Kovalev]

В сообщении от Saturday 05 January 2008 19:27:29 Dmitry V. Levin написал(а):
> Ответ на вопрос зависит от того, где определён этот символ,
> $ echo _ZN12QsciLexerCSSC2EP7QObjectPKc |c++filt
> QsciLexerCSS::QsciLexerCSS(QObject*, char const*)

Определяется в этом же пакете. 

Получаются что сначала компилируются библиотеки, потом к ним bindings for 
python. И "Verifying ELF objects..." не может найти свежескомпилированные 
библиотеки, подозреваю потому, что они в нестандартных путях.

Получается для комфортной сборки без WARNIGNS, надо указать тому, кто 
проверяет, где лежат эти библиотеки.

Сорри, я с этим новенький :-)

Кто проверяет зависимости? Этим можно управлять? Где почитать? Оно конечно и 
так собралось. Ну культара, понимаешь, требует.

-- 
Gennady Kovalev, 
BIGUR, ALT Linux Team.

Re: [devel] E: incoming x86_64 reject: qscintilla2-2-alt1.20080103

[Dmitry V. Levin]

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

On Sun, Jan 06, 2008 at 02:53:00AM +0300, Gennady Kovalev wrote:
> В сообщении от Saturday 05 January 2008 19:27:29 Dmitry V. Levin написал(а):
> > Ответ на вопрос зависит от того, где определён этот символ,
> > $ echo _ZN12QsciLexerCSSC2EP7QObjectPKc |c++filt
> > QsciLexerCSS::QsciLexerCSS(QObject*, char const*)
> 
> Определяется в этом же пакете. 
> 
> Получаются что сначала компилируются библиотеки, потом к ним bindings for 
> python. И "Verifying ELF objects..." не может найти свежескомпилированные 
> библиотеки, подозреваю потому, что они в нестандартных путях.

Нет.  То предупреждение, о котором идёт речь,
verify-elf: WARNING: ./usr/lib64/python2.4/site-packages/qsci.so: undefined symbol: _ZN12QsciLexerCSSC2EP7QObjectPKc
говорит о том, что ELF shared object по имени qsci.so для работы использует
вышеупомянутый символ, который определён в каком-то другом ELF object'е,
однако qsci.so с этим самым ELF object'ом не слинкован.

> Получается для комфортной сборки без WARNIGNS, надо указать тому, кто 
> проверяет, где лежат эти библиотеки.

Единственный правильный способ указать - это слинковать ELF object со
всеми ELF object'ами, символы из которых он использует.

в разделе Underlinking на
http://www.freesource.info/wiki/AltLinux/Sisyphus/devel/UpStream/UnderOverLinkProblems
кое-что написано на эту тему.

Некоторые апстримы не линкуют плагины с библиотеками, в которых определены
символы, используемые в этих плагинах.
Иногда такие символы определены в ELF executables, и слинковать с ними
плагины не представляется возможным.

> Кто проверяет зависимости?

В конечном итоге тот, кто загружает ELF object'ы, т.е. dynamic linker.

> Этим можно управлять? Где почитать? Оно конечно и 
> так собралось. Ну культара, понимаешь, требует.

http://people.redhat.com/drepper/dsohowto.pdf -- хорошее чтиво для старта.


-- 
ldv

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