У меня есть сценарий Perl, который я хочу использовать в системах без установленного интерпретатора Perl (например, контейнер linux). Я создаю двоичный файл с помощью PAR :: Packer, и все работает отлично.
[0] [ishpeck@centbox03 /tmp/examply]$ file ./perlthing/scripts/hello.pl
./perlthing/scripts/hello.pl: Perl script, ASCII text executable
[0] [ishpeck@centbox03 /tmp/examply]$ cat ./perlthing/scripts/hello.pl
#!/usr/bin/perl
use strict;
use warnings;
use File::Basename;
print "Hello, world!\n"
[0] [ishpeck@centbox03 /tmp/examply]$ cat Makefile
CURDIR=/tmp/examply
TOPDIR=$(CURDIR)/packaging
rpm: perlbin
sh -c 'for x in packaging/BUILD packaging/RPMS/x86_64 packaging/RPMS/x86 packaging/RPMS/arm packaging/SOURCES packaging/SPECS packaging/SRPMS; do mkdir -p $$x; done'
rpmbuild --target x86_64 -bb $(TOPDIR)/SPECS/mypackage.spec --define '_topdir $(TOPDIR)' --define '_arch x86_64' --define '_working_dir $(CURDIR)'
perlbin: perlthing/binaries/hello.pl
perlthing/binaries/hello.pl: perlthing/scripts/hello.pl Makefile
/usr/local/bin/pp -M File::** -M PAR:: --clean --verbose=2 --output=$@ $<
clean:
rm perlthing/binaries/hello.pl
[0] [ishpeck@centbox03 /tmp/examply]$ make perlbin >/dev/null ; echo $?
0
[0] [ishpeck@centbox03 /tmp/examply]$ file perlthing/binaries/hello.pl
perlthing/binaries/hello.pl: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=7d5b38a792018d0202a96ce8645b00591e7ea7c5, stripped
[0] [ishpeck@centbox03 /tmp/examply]$ ./perlthing/binaries/hello.pl
Hello, world!
Все идет нормально. Это работает даже, когда я копирую двоичный файл на машину без интерпретатора perl:
core@CoreOS-1 ~ $ which perl
which: no perl in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/opt/bin)
core@CoreOS-1 ~ $ ./hello.pl
Hello, world!
Я хочу упаковать это в RPM:
[0] [ishpeck@centbox03 /tmp/examply]$ cat packaging/SPECS/mypackage.spec
Name: ishy-mypackage
Version: 0.1
Release: 1%{?dist}
Summary: My example package
License: MIT
URL: http://ishpeck.net
%description
This is my example package that includes a perl script bundled as a binary via PAR::Packer
%prep
echo "Prepare scriptlet is empty"
%build
echo "Nothing really to do"
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/local/bin/
cp %{_working_dir}/perlthing/binaries/hello.pl $RPM_BUILD_ROOT/usr/local/bin/
%files
/usr/local/bin/hello.pl
[0] [ishpeck@centbox03 /tmp/examply]$ grep rpmbuild Makefile
rpmbuild --target x86_64 -bb $(TOPDIR)/SPECS/mypackage.spec --define '_topdir $(TOPDIR)' --define '_arch x86_64' --define '_working_dir $(CURDIR)'
[0] [ishpeck@centbox03 /tmp/examply]$ make
Но когда я устанавливаю пакет, двоичный файл perl больше не работает!
[0] [ishpeck@centbox03 /tmp/examply]$ sudo rpm -i ./packaging/RPMS/x86_64/ishy-mypackage-0.1-1.el7.x86_64.rpm
[0] [ishpeck@centbox03 /tmp/examply]$ which hello.pl
/usr/local/bin/hello.pl
[0] [ishpeck@centbox03 /tmp/examply]$ hello.pl
Usage: /usr/local/bin/hello.pl [ -Alib.par ] [ -Idir ] [ -Mmodule ] [ src.par ] [ program.pl ]
/usr/local/bin/hello.pl [ -B|-b ] [-Ooutfile] src.par
Removing files in "/tmp/par-6973687065636b/temp-51174"
Undefined subroutine &File::Find::finddepth called at -e line 11.
END failed--call queue aborted at -e line 616.
Я не думаю, что это проблема того, как я использую pp чтобы сгенерировать двоичный файл, потому что он, кажется, работает везде, если я просто скопирую его напрямую. Мой мозг хочет свалить вину (как я использую) rpmbuild но я даже не знаю, с чего начать.
Есть ли какие-то загадочные подробности о rpmbuild, которые мне здесь не хватает?
Макросы rpmbuild по умолчанию включают strip
команды, которые мешают любой магии PAR :: Packer.
Если взять ваши источники, я могу воспроизвести проблему на CentOS 7, perl v5.16.3. Добавьте это вверху вашей спецификации:
%global __os_install_post %{nil}
двоичные файлы в корне сборки не изменены, и программа работает. Я не совсем уверен, почему, вы можете спросить подробности у сопровождающих Perl rpm или других хакеров Perl.
Я заметил постоянное 100-кратное замедление упакованного двоичного файла по сравнению с реальным интерпретатором perl. Для нетривиальных программ разница может быть менее значительной. Даже эта тривиальная сборка имеет размер 4 МБ.
Я ценю привнесение силы Бензопила швейцарской армии для непросвещенных дистрибутивов, но учтите, что нативный двоичный файл вряд ли повысит производительность.