Назад | Перейти на главную страницу

Как безопасно удалить строку пути из скомпилированной библиотеки, не повредив библиотеку?

Мой процесс сборки RPM жалуется на строку пути buildroot, появляющуюся внутри нескольких .so файлы. Я пробовал использовать оба sed и perl для замены этой строки регулярным выражением на '', но пока это молчит check-buildroot, он повреждает файл .so и вызывает segfault для всего, что его использует.

Эта строка, по-видимому, не является частью rpath, поскольку chrpath --delete не заглушает сообщение об ошибке от check-buildroot. Я понятия не имею, почему путь buildroot появляется в этих .so файлы.

Итак, каков же "правильный" способ предотвратить появление этого пути buildroot в .so файлы?

РЕДАКТИРОВАТЬ: Вот мой файл спецификации:

%{!?tgrelease: %define tgrelease() %2}
%if 0%{?amzn}

# Prevent /usr/lib/rpm/check-buildroot from running, because the only remedy we've found to silence its error messages
# also corrupts the .so files it complains about.
%define __arch_install_post /usr/lib/rpm/check-rpaths

%define __python python
%define __python_ver python2.6
%define __python_prefix python
%else
%define __python python2.6
%define __python_ver python2.6
%define __python_prefix python26
%endif
%define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")

%define __package directory
%define __package_safe %(echo %{__package} | sed 's/[-. ]/_/g')
%define __pip_package %(echo %{__package} | sed 's/_/-/g' | tr '[A-Z]' '[a-z]')

%define __configdir etc/prod
%define __django_root REDACTED
%define __requirements REDACTED

Name:           %{__package}
Version:        %{__version}
Release:        %tgrelease 0 1
Summary:        REDACTED
Group:          Development/Languages
License:        Restricted
Source0:        %{rname}/%{name}-%{version}.tar.gz
BuildRoot:      %{_tmppath}/%{name}-%(%{__id_u} -n)

BuildRequires:  %{__python_prefix}
BuildRequires:  %{__python_prefix}-setuptools
BuildRequires:  %{__python_prefix}-virtualenv
# Uncomment this when we get git as an RPM on RH6
BuildRequires:  git
BuildRequires:  openldap-devel
BuildRequires:  libxml2-devel
BuildRequires:  libxslt-devel
BuildRequires:  chrpath

Requires:  %{__python_prefix}
Requires:  %{__python_prefix}-virtualenv
Requires:  openldap
Requires:  mysql

%description
REDACTED

%prep
%setup -q -n %{name}-%{version}

%install
rm -rf $RPM_BUILD_ROOT

%{__install} -d %{buildroot}%{__django_root}/conf.d
%{__install} -d %{buildroot}%{__django_root}/cron/daily
%{__install} -d %{buildroot}%{__django_root}/cron/hourly
%{__install} -d %{buildroot}%{__django_root}/%{name}/ve
%{__install} -d %{buildroot}%{__django_root}/%{name}/current_settings
%{__install} -d %{buildroot}%{__django_root}/html/static

#virtualenv
virtualenv-2.6 --no-site-packages %{buildroot}%{__django_root}/%{name}/ve
source  %{buildroot}%{__django_root}/%{name}/ve/bin/activate
pip install -r %{__requirements}
virtualenv-2.6 --relocatable %{buildroot}%{__django_root}/%{name}/ve
deactivate


# Put the settings file into current_settings and add the symlink we will want when installed.
%{__install} -m 664 %{buildroot}%{__django_root}/%{name}/ve/src/%{__pip_package}/%{__configdir}/settings/settings.py %{buildroot}%{__django_root}/%{name}/current_settings/settings.py
rm -f %{__django_root}/%{name}/current_settings/settings.py
ln -sf %{__django_root}/%{name}/current_settings/settings.py %{buildroot}%{__django_root}/%{name}/ve/src/%{__pip_package}/directory/settings/settings.py

#fix the wrong paths in easy_install.pth
perl -p -i -e "s#$RPM_BUILD_ROOT##g" %{buildroot}%{__django_root}/%{name}/ve/lib/%{__python_ver}/site-packages/easy-install.pth
#fix the wrong paths in activate
perl -p -i -e "s#$RPM_BUILD_ROOT##g" %{buildroot}%{__django_root}/%{name}/ve/bin/activate*

# The Linux build hosts we use have recently become persnickety about references to the build root in deployed files.
# egg-links and *.so files in our site-packages folder have this problem:
# THIS IS COMMENTED OUT BECAUSE IT CORRUPTS THE *.so FILES.
#find %{buildroot} -name "*.egg-link" -o -name "*.so" -o -name "*.txt" | xargs perl -p -i -e "s{\Q$RPM_BUILD_ROOT\E}{}g"

# The Linux build slaves we use are persnickety about rpaths in libraries pointing to directories that don't exist.
# So we use chrpath to purge them.
chrpath --delete %{buildroot}REDACTED/ve/lib/python2.6/site-packages/_ldap.so

# Un prelink everything
# http://www.alexhudson.com/2013/05/24/packaging-a-virtualenv-really-not-relocatable/
find %{buildroot}%{__django_root}/%{name}/ve -type f -perm /u+x,g+x -exec /usr/sbin/prelink -u {} \;
# re-point the lib64 symlink - not needed on newer virtualenv
if test -d %{buildroot}%{__django_root}/%{name}/ve/lib64; then
  rm %{buildroot}%{__django_root}/%{name}/ve/lib64
  ln -sf %{__django_root}/%{name}/ve/lib %{buildroot}%{__django_root}/%{name}/ve/lib64
fi


%clean
rm -rf $RPM_BUILD_ROOT

%preun
if [ $1 -eq 0 ]; then
    rm -rf %{__django_root}/%{name}/html
    rm -rf %{__django_root}/whoosh
fi

%files
%defattr(-,root,root,-)
# Prevent RPM from deleting our manually edited settings files during upgrade.
%config(noreplace) %attr(660,apache,apache) %{__django_root}/conf.d/%{name}_apache.conf
%config(noreplace) %attr(660,apache,apache) %{__django_root}/%{name}/current_settings/settings.py
%attr(775,apache,apache) %{__django_root}/%{name}/html/static
%{__django_root}/%{name}/ve
%{__django_root}/%{name}/current_settings

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

На этапе настройки сборки я подумал, что лучше всего использовать PREFIX инструмента, чтобы установить каталог установки в / path / to / buildroot /

Это вызывало точную проблему с проверкой-buildroot нахождения пути внутри собранных файлов.

Мне помогло выполнить настройку с PREFIX = / вместо этого, чтобы файлы прошли проверку, а затем DESTDIR=/path/to/buildroot make install, который заставил удалить файлы в соответствующем месте.

Возможно, вы захотите изучить это. Создайте проект / библиотеку, как если бы вы собирались установить его в обычном режиме, и выполните перемещение в корневой каталог сборки rpm только на более позднем этапе, используя любые средства, предоставляемые вашей соответствующей системой сборки / установки.