Perl in the VDT

These are notes Tim took while Nate was talking, so they’re a bit sketchy, but maybe worth something.

Background

• There are two layers of wrappers around Perl.
• VDT-Core-Bin builds a vdt/bin/perl.
• In SLF, there are two perls in your PATH, the first of which is broken. So, all our scripts call /usr/bin/env perl, and so we just make sure that vdt/bin/perl comes first.
• vdt-untar fixes any Perl #! lines to use /usr/bin/env; this has the side-effect that any command-line switches to Perl are dropped, because env doesn’t support them.
• vdt/bin/perl goes through the PATH and execs the first perl that is NOT the broken SLF perl.

Perl Package for 32-on-64-bit install

• This package is required by Perl-Modules. In this case, we bring along our own 32-bit Perl, but it can’t find its libraries because its libraries are hard-coded in the executable.
• If we didn’t use Globus, we would set PERL5LIB in the environment and everything would be happy. BUT, Globus scrubs the environment before forking the jobmanager (including PERL5LIB and VDT_LOCATION), so this doesn’t work. So $VDT_LOCATION/perl/bin/perl is a wrapper that sets the Perl library path appropriately and calls perl/bin/perl.real. Why is it written in C? Because you can’t have a #! line that references another script with another #! line.
• Note: In the VDT source code, Perl/nmi/perl.c contains a hard-coded reference to the version of Perl that is built. It must match the version declared in the defs file or 32-on-64-bit installs will fail right after the Perl package is installed. I know of no automatic way to synchronize perl.c and defs, so it must be done manually.

Perl 5.10

This update is due out in the next 6 months or so, is going to be relocatable and so this problem should go away. In which case, we would bring along Perl 5.10 for the 32-bit case only, but the wrapper wouldn’t be needed.