Отсутствует библиотека для установки rpm, если она присутствует в файле rpm

Я создаю файл rpm для centos, но когда я пытаюсь установить его на чистую машину, происходит сбой:

 --> Running transaction check
 ---> Package grass.x86_64 0:6.4.4-1.el6 will be installed
 --> Processing Dependency: libgrass_rli.so()(64bit) for package: grass-6.4.4-1.el6.x86_64
 --> Finished Dependency Resolution Error: Package: grass-6.4.4-1.el6.x86_64 (/grass-6.4.4-1.el6.x86_64)
            Requires: libgrass_rli.so()(64bit)

что было бы хорошо, за исключением того, что rpm содержит libgrass_rli.so.

 [vagrant@localhost ~]$ rpm -qilp /vagrant_rpms/grass-6.4.4-1.el6.x86_64.rpm | grep _rli
 /usr/local/lib/libgrass_rli.6.4.4.so 
 /usr/local/lib/libgrass_rli.so

Я экспериментировал с различными строками в spec-файле безрезультатно, может кто-нибудь увидеть, что не так?

ИЗМЕНИТЬ

[vagrant@localhost ~]$ rpm -qp --provides /vagrant_rpms/grass-6.4.4-1.el6.x86_64.rpm                                                                            
libgrass_I.6.4.4.so()(64bit)                                                    
libgrass_Iortho.6.4.4.so()(64bit)                                               
libgrass_arraystats.6.4.4.so()(64bit)                                           
libgrass_bitmap.6.4.4.so()(64bit)                                               
libgrass_btree.6.4.4.so()(64bit)                                                
libgrass_cdhc.6.4.4.so()(64bit)                                                 
libgrass_cluster.6.4.4.so()(64bit)                                              
libgrass_datetime.6.4.4.so()(64bit)                                             
libgrass_dbmibase.6.4.4.so()(64bit)                                             
libgrass_dbmiclient.6.4.4.so()(64bit)                                           
libgrass_dbmidriver.6.4.4.so()(64bit)                                           
libgrass_dbstubs.6.4.4.so()(64bit)                                              
libgrass_dgl.6.4.4.so()(64bit)                                                  
libgrass_dig2.6.4.4.so()(64bit)                                                 
libgrass_display.6.4.4.so()(64bit)                                              
libgrass_driver.6.4.4.so()(64bit)                                               
libgrass_dspf.6.4.4.so()(64bit)
libgrass_edit.6.4.4.so()(64bit)
libgrass_form.6.4.4.so()(64bit)
libgrass_g3d.6.4.4.so()(64bit)
libgrass_gis.6.4.4.so()(64bit)
libgrass_gmath.6.4.4.so()(64bit)
libgrass_gpde.6.4.4.so()(64bit)
libgrass_gproj.6.4.4.so()(64bit)
libgrass_interpdata.6.4.4.so()(64bit)
libgrass_interpfl.6.4.4.so()(64bit)
libgrass_lidar.6.4.4.so()(64bit)
libgrass_linkm.6.4.4.so()(64bit)
libgrass_lrs.6.4.4.so()(64bit)
libgrass_neta.6.4.4.so()(64bit)
libgrass_nviz.6.4.4.so()(64bit)
libgrass_ogsf.6.4.4.so()(64bit)
libgrass_pngdriver.6.4.4.so()(64bit)
libgrass_psdriver.6.4.4.so()(64bit)
libgrass_qtree.6.4.4.so()(64bit)
libgrass_raster.6.4.4.so()(64bit)
libgrass_rli.6.4.4.so()(64bit)
libgrass_rli.so
libgrass_rowio.6.4.4.so()(64bit)
libgrass_rtree.6.4.4.so()(64bit)
libgrass_segment.6.4.4.so()(64bit)
libgrass_shape.6.4.4.so()(64bit)
libgrass_sim.6.4.4.so()(64bit)
libgrass_sites.6.4.4.so()(64bit)
libgrass_sqlp.6.4.4.so()(64bit)
libgrass_stats.6.4.4.so()(64bit)
libgrass_symb.6.4.4.so()(64bit)
libgrass_trans.6.4.4.so()(64bit)
libgrass_vask.6.4.4.so()(64bit)
libgrass_vect.6.4.4.so()(64bit)
libgrass_vedit.6.4.4.so()(64bit)
grass = 6.4.4-1.el6
grass(x86-64) = 6.4.4-1.el6

Также извлеченный файл выглядит нормально:

[vagrant@localhost ~]$ file /tmp/libgrass_rli.6.4.4.so
/tmp/libgrass_rli.6.4.4.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped

rpmbuild rpm grass
person Ian Turton    schedule 12.12.2014    source источник
comment
Что говорит rpm -qp --provides /vagrant_rpms/grass-6.4.4-1.el6.x86_64.rpm? Если вы извлечете эту библиотеку из rpm rpm2cpio /vagrant_rpms/grass-6.4.4-1.el6.x86_64.rpm | cpio -i --to-stdout ./usr/local/lib/libgrass_rli.6.4.4.so > /tmp/libgrass_rli.6.4.4.so, что file /tmp/libgrass_rli.6.4.4.so скажет об этом?   -  person Etan Reisner    schedule 12.12.2014
comment
Я добавил эти выходы, но они выглядят нормально для меня   -  person Ian Turton    schedule 12.12.2014
comment
Обратите внимание, что ваш список «предоставляет» действительно не содержит функции, на которую жалуется RPM: libgrass_rli.so()(64bit). В нем перечислены libgrass_rli.so и libgrass_rli.6.4.4.so()(64bit), но они оба разные. Возможно, libgrass_rli.so, который вы упаковываете, является неработающей символической ссылкой. Я обновил свой ответ, чтобы учесть эту возможность.   -  person John Bollinger    schedule 12.12.2014
comment
Эти имена файлов интересны. Разве версии обычно не идут после .so, а не перед ним? Что говорит nm /tmp/libgrass_rli.6.4.4.so?   -  person Etan Reisner    schedule 12.12.2014
comment
Я видел, что если библиотека не является исполняемой, например, режим 0666, rpmbuild не распознает ее при построении списка поставок. Изменение всех библиотек с помощью chmod +x *.so* устранило мою проблему.   -  person Danny    schedule 25.03.2021

Ответы (3)


arrow_upward
2
arrow_downward

rpmbuild обычно сканирует все файлы, упакованные в RPM, для автоматической идентификации общих библиотек, предоставляемых RPM, и требования RPM могут быть удовлетворены сами по себе. Таким образом, есть две основные возможности:

  • возможно, RPM содержит i386 (т.е. 32-битную) версию библиотеки, тогда как на самом деле требуется 64-битная версия, или по какой-то другой причине упакованный файл имеет неправильный тип;
  • в качестве альтернативы, автоматическое сканирование rpmbuild могло быть отключено или испорчено (это может быть функцией файла спецификации).

Неправильная архитектура библиотеки маловероятна, если только вы не упаковываете предварительно собранную библиотеку или если вы не создаете 32-разрядную и 64-разрядную библиотеки для одного и того же RPM (и не можете установить последнюю или устанавливаете обе в одно и то же место, поэтому что один бьет другого).

Так как вы сами разрабатываете RPM, я полагаю, вы знаете, лажаете ли вы с авто-предложениями.

person John Bollinger    schedule 12.12.2014
comment
Кажется, все указывает на то, что он 64-битный (как и требуется), и я не возился с автопредоставлением (о котором я знаю) - person Ian Turton; 12.12.2014

arrow_upward
12
arrow_downward

Вероятной причиной того, что ваша разделяемая библиотека не обнаруживается механизмом «автоматического предоставления», является то, что она не является исполняемой.

Добавьте что-то вроде этого в раздел %install:

find %buildroot -type f \( -name '*.so' -o -name '*.so.*' \) -exec chmod 755 {} +

Источник.

person Roman Cheplyaka    schedule 02.10.2016
comment
Вау, хороший. Большое спасибо. - person drookie; 15.04.2018
comment
Искали полдня. По крайней мере, в CentOS7 с redhat-rpm-config-9.1.0 общие библиотеки должны быть исполняемыми. - person xoryves; 29.05.2018

arrow_upward
2
arrow_downward

Если ни один из других существующих ответов не работает для вас, убедитесь, что вы установили SONAME для своей библиотеки. Это задается с помощью параметра компоновщика 'soname', который добавляет метаинформацию для указания имени общего объекта библиотеки. Раздел Автоматические зависимости раздела "Максимальное Руководство по RPM отлично объясняет, как это связано с процессом сборки rpm.

Этот ответ (на другой вопрос) довольно хорошо объясняет цель SONAME, а сам вопрос объясняет синтаксис.

Вот наиболее важные части этого ответа, слегка отредактированные для ясности и грамматики:

soname используется для указания того, какую бинарную совместимость с API поддерживает ваша библиотека.

SONAME используется компоновщиком во время компиляции для определения из файла библиотеки фактической версии целевой библиотеки. gcc -lNAME будет искать libNAME.so (символическую ссылку или файл), а затем извлекать его SONAME, который, безусловно, будет более конкретным (например, libfoo.so ссылается на libfoo.so.1.2.4, который содержит SONAME libfoo.so.1).

И вот синтаксис:

gcc -shared -fPIC -Wl,-soname,libfoo.so.1 -o libfoo.so.1.2.4 foo.c

См. также раздел Program Library HOWTO в «Создание общей библиотеки» для дальнейшего объяснения.

person Robert    schedule 25.02.2020