[devel] db4.7-devel-static

[devel] db4.7-devel-static

[Led]

/usr/bin/ld: /usr/lib64/gcc/x86_64-alt-linux/4.4.0/../../../../lib64/libdb-4.7.a(db_err.o): 
relocation R_X86_64_32 against `a local symbol' can not be used when making a 
shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-alt-linux/4.4.0/../../../../lib64/libdb-4.7.a: could not 
read symbols: Bad value
collect2: ld returned 1 exit status

Это бага в сборке db4.7 или нужно как-то по-другому использовать libdb-4.7.a ?

-- 
Led

Re: [devel] db4.7-devel-static

[Dmitry V. Levin]

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

On Mon, May 18, 2009 at 11:03:32PM +0300, Led wrote:
> /usr/bin/ld: /usr/lib64/gcc/x86_64-alt-linux/4.4.0/../../../../lib64/libdb-4.7.a(db_err.o): 
> relocation R_X86_64_32 against `a local symbol' can not be used when making a 
> shared object; recompile with -fPIC
> /usr/lib64/gcc/x86_64-alt-linux/4.4.0/../../../../lib64/libdb-4.7.a: could not 
> read symbols: Bad value
> collect2: ld returned 1 exit status
> 
> Это бага в сборке db4.7 или нужно как-то по-другому использовать libdb-4.7.a ?

Обычно статические библиотеки, которые сопровождают динамические, собирают
без -fpic, поскольку с ними обычно линкуются статически.  Например,
так собирается rpm-static с -ldb.

Другое дело, если для статической библиотеки нет парной динамической.
Например, мне в понедельник показали libmysqld.a, который тоже
скомпилирован без -fpic, однако libmysqld.so не существует, и это создаёт
проблемы.


-- 
ldv

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

Re: [devel] db4.7-devel-static

[Led]

On Tuesday, 19 May 2009 01:25:50 Dmitry V. Levin wrote:
> On Mon, May 18, 2009 at 11:03:32PM +0300, Led wrote:
> > /usr/bin/ld:
> > /usr/lib64/gcc/x86_64-alt-linux/4.4.0/../../../../lib64/libdb-4.7.a(db_er
> >r.o): relocation R_X86_64_32 against `a local symbol' can not be used when
> > making a shared object; recompile with -fPIC
> > /usr/lib64/gcc/x86_64-alt-linux/4.4.0/../../../../lib64/libdb-4.7.a:
> > could not read symbols: Bad value
> > collect2: ld returned 1 exit status
> >
> > Это бага в сборке db4.7 или нужно как-то по-другому использовать
> > libdb-4.7.a ?
>
> Обычно статические библиотеки, которые сопровождают динамические, собирают
> без -fpic, поскольку с ними обычно линкуются статически.  Например,
> так собирается rpm-static с -ldb.
>
> Другое дело, если для статической библиотеки нет парной динамической.
> Например, мне в понедельник показали libmysqld.a, который тоже
> скомпилирован без -fpic, однако libmysqld.so не существует, и это создаёт
> проблемы.

Как бы то ни было, но сборка libdb-4.7 c явно указанным --with-pic для x86_64 
проблему решает.
Если так и должно быть, и это не бага, значит в багзиллу мне идти нЕзачем?

-- 
Led

Re: [devel] db4.7-devel-static

[Dmitry V. Levin]

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

On Tue, May 19, 2009 at 01:28:42AM +0300, Led wrote:
> On Tuesday, 19 May 2009 01:25:50 Dmitry V. Levin wrote:
> > On Mon, May 18, 2009 at 11:03:32PM +0300, Led wrote:
> > > /usr/bin/ld:
> > > /usr/lib64/gcc/x86_64-alt-linux/4.4.0/../../../../lib64/libdb-4.7.a(db_er
> > >r.o): relocation R_X86_64_32 against `a local symbol' can not be used when
> > > making a shared object; recompile with -fPIC
> > > /usr/lib64/gcc/x86_64-alt-linux/4.4.0/../../../../lib64/libdb-4.7.a:
> > > could not read symbols: Bad value
> > > collect2: ld returned 1 exit status
> > >
> > > Это бага в сборке db4.7 или нужно как-то по-другому использовать
> > > libdb-4.7.a ?
> >
> > Обычно статические библиотеки, которые сопровождают динамические, собирают
> > без -fpic, поскольку с ними обычно линкуются статически.  Например,
> > так собирается rpm-static с -ldb.
> >
> > Другое дело, если для статической библиотеки нет парной динамической.
> > Например, мне в понедельник показали libmysqld.a, который тоже
> > скомпилирован без -fpic, однако libmysqld.so не существует, и это создаёт
> > проблемы.
> 
> Как бы то ни было, но сборка libdb-4.7 c явно указанным --with-pic для x86_64 
> проблему решает.

В Сизифе 49 исходных пакетов линкуются с -ldb, и проблемы не испытывают.
Зачем вы линкуете libdb.a в ELF shared object при наличии libdb.so?
Расскажите нам, какую проблему вы решаете.


-- 
ldv

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

Re: [devel] db4.7-devel-static

[Led]

On Tuesday, 19 May 2009 01:33:53 Dmitry V. Levin wrote:
> On Tue, May 19, 2009 at 01:28:42AM +0300, Led wrote:
> > On Tuesday, 19 May 2009 01:25:50 Dmitry V. Levin wrote:
> > > On Mon, May 18, 2009 at 11:03:32PM +0300, Led wrote:
> > > > /usr/bin/ld:
> > > > /usr/lib64/gcc/x86_64-alt-linux/4.4.0/../../../../lib64/libdb-4.7.a(d
> > > >b_er r.o): relocation R_X86_64_32 against `a local symbol' can not be
> > > > used when making a shared object; recompile with -fPIC
> > > > /usr/lib64/gcc/x86_64-alt-linux/4.4.0/../../../../lib64/libdb-4.7.a:
> > > > could not read symbols: Bad value
> > > > collect2: ld returned 1 exit status
> > > >
> > > > Это бага в сборке db4.7 или нужно как-то по-другому использовать
> > > > libdb-4.7.a ?
> > >
> > > Обычно статические библиотеки, которые сопровождают динамические,
> > > собирают без -fpic, поскольку с ними обычно линкуются статически. 
> > > Например, так собирается rpm-static с -ldb.
> > >
> > > Другое дело, если для статической библиотеки нет парной динамической.
> > > Например, мне в понедельник показали libmysqld.a, который тоже
> > > скомпилирован без -fpic, однако libmysqld.so не существует, и это
> > > создаёт проблемы.
> >
> > Как бы то ни было, но сборка libdb-4.7 c явно указанным --with-pic для
> > x86_64 проблему решает.
>
> В Сизифе 49 исходных пакетов линкуются с -ldb, и проблемы не испытывают.
> Зачем вы линкуете libdb.a в ELF shared object при наличии libdb.so?
> Расскажите нам, какую проблему вы решаете.

Спасибо, теперь, кажется, понятно. Это из-за "-ldb-4.7" в команде линковки и 
отстутствия "-L/lib64" в ней же. А симлинк /usr/lib64/libdb-4.7.so нельзя 
сделать? Или это приведёт к дополнительным проблемам?

-- 
Led

Re: [devel] db4.7-devel-static

[Dmitry V. Levin]

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

On Tue, May 19, 2009 at 02:07:57AM +0300, Led wrote:
[...]
> Спасибо, теперь, кажется, понятно. Это из-за "-ldb-4.7" в команде линковки и 
> отстутствия "-L/lib64" в ней же. А симлинк /usr/lib64/libdb-4.7.so нельзя 
> сделать? Или это приведёт к дополнительным проблемам?

Да, этот симлинк придётся сделать.  К счастью, только libdb используют
такую схему именования библиотек, поэтому других пакетов эта проблема не
касается.

Поясню ситуацию:
Порядок перебора каталогов с библиотеками у GNU ld отличается от ld.so,
а именно, /lib просматривается после /usr/lib.
Я обсуждал эту тему с апстримом 5 лет назад, и мы сошлись во мнении, что
изменение этого неочевидного на первый взгляд порядка может сломать multilib.
Если интересно, то я могу откопать цитаты из той переписки.


-- 
ldv

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

Re: [devel] db4.7-devel-static

[Led]

On Tuesday, 19 May 2009 02:48:22 Dmitry V. Levin wrote:
> On Tue, May 19, 2009 at 02:07:57AM +0300, Led wrote:
> [...]
>
> > Спасибо, теперь, кажется, понятно. Это из-за "-ldb-4.7" в команде
> > линковки и отстутствия "-L/lib64" в ней же. А симлинк
> > /usr/lib64/libdb-4.7.so нельзя сделать? Или это приведёт к дополнительным
> > проблемам?
>
> Да, этот симлинк придётся сделать.

Ок, спасибо, если сделаете:)

> К счастью, только libdb используют 
> такую схему именования библиотек, поэтому других пакетов эта проблема не
> касается.
>
> Поясню ситуацию:
> Порядок перебора каталогов с библиотеками у GNU ld отличается от ld.so,
> а именно, /lib просматривается после /usr/lib.
> Я обсуждал эту тему с апстримом 5 лет назад, и мы сошлись во мнении, что
> изменение этого неочевидного на первый взгляд порядка может сломать
> multilib. Если интересно, то я могу откопать цитаты из той переписки.

Не, ненужно "откапывать" - наверное это логично. Тем более, что добавление 
симлинка в /usr/lib всё решает.

-- 
Led

Re: [devel] db4.7-devel-static

[Evgeny Sinelnikov]

19 мая 2009 г. 4:00 пользователь Led <ledest@gmail.com> написал:
> On Tuesday, 19 May 2009 02:48:22 Dmitry V. Levin wrote:
>> On Tue, May 19, 2009 at 02:07:57AM +0300, Led wrote:
>> [...]
>>
>> > Спасибо, теперь, кажется, понятно. Это из-за "-ldb-4.7" в команде
>> > линковки и отстутствия "-L/lib64" в ней же. А симлинк
>> > /usr/lib64/libdb-4.7.so нельзя сделать? Или это приведёт к дополнительным
>> > проблемам?
>>
>> Да, этот симлинк придётся сделать.
>
> Ок, спасибо, если сделаете:)
>
>> К счастью, только libdb используют
>> такую схему именования библиотек, поэтому других пакетов эта проблема не
>> касается.
>>
>> Поясню ситуацию:
>> Порядок перебора каталогов с библиотеками у GNU ld отличается от ld.so,
>> а именно, /lib просматривается после /usr/lib.
>> Я обсуждал эту тему с апстримом 5 лет назад, и мы сошлись во мнении, что
>> изменение этого неочевидного на первый взгляд порядка может сломать
>> multilib. Если интересно, то я могу откопать цитаты из той переписки.
>
> Не, ненужно "откапывать" - наверное это логично. Тем более, что добавление
> симлинка в /usr/lib всё решает.
>

Вообще-то странно... Я уже указывал в личной переписке с ldv@ по
поводу похожих проблем с линковкой с libdb-4.7 при пересборке питона,
причём на 32-битной системе.

В некоторых конфигурациях, в каких именно я так пока не успел
разобраться, линковка с libdb-4.7 не работает. Хотя, при этом, в
хешере та же самая сборка отрабатывает нормально... На пересборке
питона это ошибка стабильно проявляется. Может быть и у вас проявится?

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] db4.7-devel-static

[Dmitry V. Levin]

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

On Tue, May 19, 2009 at 04:56:33AM +0400, Evgeny Sinelnikov wrote:
> 19 мая 2009 г. 4:00 пользователь Led <ledest@gmail.com> написал:
> > On Tuesday, 19 May 2009 02:48:22 Dmitry V. Levin wrote:
> >> On Tue, May 19, 2009 at 02:07:57AM +0300, Led wrote:
> >> [...]
> >>
> >> > Спасибо, теперь, кажется, понятно. Это из-за "-ldb-4.7" в команде
> >> > линковки и отстутствия "-L/lib64" в ней же. А симлинк
> >> > /usr/lib64/libdb-4.7.so нельзя сделать? Или это приведёт к дополнительным
> >> > проблемам?
> >>
> >> Да, этот симлинк придётся сделать.
> >
> > Ок, спасибо, если сделаете:)
> >
> >> К счастью, только libdb используют
> >> такую схему именования библиотек, поэтому других пакетов эта проблема не
> >> касается.
> >>
> >> Поясню ситуацию:
> >> Порядок перебора каталогов с библиотеками у GNU ld отличается от ld.so,
> >> а именно, /lib просматривается после /usr/lib.
> >> Я обсуждал эту тему с апстримом 5 лет назад, и мы сошлись во мнении, что
> >> изменение этого неочевидного на первый взгляд порядка может сломать
> >> multilib. Если интересно, то я могу откопать цитаты из той переписки.
> >
> > Не, ненужно "откапывать" - наверное это логично. Тем более, что добавление
> > симлинка в /usr/lib всё решает.
> 
> Вообще-то странно... Я уже указывал в личной переписке с ldv@ по
> поводу похожих проблем с линковкой с libdb-4.7 при пересборке питона,
> причём на 32-битной системе.
> 
> В некоторых конфигурациях, в каких именно я так пока не успел
> разобраться, линковка с libdb-4.7 не работает. Хотя, при этом, в
> хешере та же самая сборка отрабатывает нормально... На пересборке
> питона это ошибка стабильно проявляется. Может быть и у вас проявится?

Вероятно, вы тоже наступили на эти грабли: в сборочную среду питона
libdb-4.7.a не устанавливается, поэтому всё собирается.

Впрочем, это уже не важно, поскольку задание #6722 уже выполнилось.


-- 
ldv

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

Re: [devel] db4.7-devel-static

[Evgeny Sinelnikov]

19 мая 2009 г. 5:04 пользователь Dmitry V. Levin <ldv@altlinux.org> написал:
> Вероятно, вы тоже наступили на эти грабли: в сборочную среду питона
> libdb-4.7.a не устанавливается, поэтому всё собирается.
>

Ах, вот оно в чём дело... Действительно, при удалении
libdb4.7-devel-static всё пересобирается.

> Впрочем, это уже не важно, поскольку задание #6722 уже выполнилось.
>

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


-- 
Sin (Sinelnikov Evgeny)