Linux binary fails to start with 0.33

[random]

random@delly:~$ Desktop/padre-0.33-x86_32-linux-gnu-thread-multi 
run3(): undefined command at ORLite/Migrate.pm line 104
BEGIN failed--compilation aborted at Padre/DB.pm line 22.
Compilation failed in require at Padre.pm line 33.
BEGIN failed--compilation aborted at Padre.pm line 33.
Compilation failed in require at script/padre line 49.

System is Debian Squeeze 32bit

The actual root of the problem seems to be Probe::Perl->find_perl_interpreter() which fails to return the currently running perl when running under PAR. A trivial patch is to have ORLite::Migrate use a default perl interpreter of "perl" which then only requires the target platform to have one. A better approch is to fix up Probe::Perl to return wathever can be considered right for a binary PAR packed executable.

The same goes for 0.32 (also 32bit version)

Perl and WxPerl? versions:

This is perl, v5.10.0 built for i486-linux-gnu-thread-multi
Wx Version: 0.89 wxWidgets 2.8.7

[random]

Proposed quickfix for ORLite-Migrate when running under PAR and perl interpreter is not available in same location as on build machine

[random]

This problem only occurs when the database requires an schema update with the migrate-X.pl scripts, which are currently run by forking a perl interpreter instead of doing this inline.

[explorer]

The ORLite/Migrate message only is showed one time, because the perl interpreter path is saved at ~/.padre/config.db after the ORLite::Migrate patch. So, if you install a new Padre binary, you don't will see this bug because Probe::Perl will return the path written at config.db. BUT the problem will remain at Probe::Perl into a fresh install.

[explorer]

After the patch, it show another bug:

explorer@portatil:~/Documents/Software> ./padre-0.33-x86_32-linux-gnu-thread-multi
Can't locate object method "select" via package "Padre::DB::HostConfig" at Padre/Config/Host.pm line 37.

[tsee]

This is a more general issue. Various parts of the codebase want to use the currently running perl interpreter to run other stuff. Unfortunately, that's not currently possible in a PAR packaged executable.

To fix the underlying PAR issue, I think it would be necessary to patch the parl C code in the PAR::Packer distribution so that it can run external code. Naturally, there'd be security implications that I'm mostly unaware of, as usual. And it'd take some effort, too, I fear.

[random]

This is actually already fixed downstream for debian at least (on 32bit and 64bit systems). So it can probably be closed.

[zenogantner]

Close because of last comment. Re-open if the problem still exists.