CompilingPerl: Difference between revisions
m (2 revisions imported) |
(No difference)
|
Latest revision as of 15:03, 6 April 2016
Abstract
At the time this article was written (14-Feb-2004), Best Practical recommends using perl 5.8.3 with RT. But since perl 5.8.3 is still fairly new (it was released 14-Jan-2004), most OS distributions don't yet provide packages for it. You must therefore build it yourself.
The present article aims at giving directions on how to build perl 5.8.3 properly (on Unix-type platforms) to function with RT, assuming your already have RT installed with a perl that came with your OS distribution.
Note: Please read the article in its entirety before starting. This will help you get a better handle on actually how much work is required and how much time it might take you.
Missing Parts
As of now this article is incomplete with respect to:
- setuid options while building perl
Hopefully someone knowledgeable in these areas will fill these parts in.
Sorce code requirments
- The perl source code. here
- mod_perl users need its source code. here
- static linkage require Apache rebuild. sources here
The Recipe
Part I: Building Perl
- Untar the source code and cd into the created directory (perl-5.8.3)
- rm -f config.sh Policy.sh
- sh Configure
This part is where you have to make the right choices. For most of the numerous questions you may simply select the default value. But pay close attention to these questions:
Build a threading Perl? [n]
Nothing in RT uses threads, so unless you need them for something else, answer no. Also Test::More, one of the pre-requisite modules does not pass "make test" with a threaded perl. (See Bug 6782 rt.cpan.org)
Installation prefix to use? (~name ok) [/usr/local]
Here I recommend that you do not squish your current perl as it will make it hard for you to fallback if something goes wrong. I usually install it in /usr/local/perl-5.8.3. That way I'm sure it's isolated under it's own directory tree.
Do you want to install perl as /usr/bin/perl? [n]
Here you probably want to say no and do it manually later using a symlink.
Build a shared libperl.so (y/n) [n]
If you plan on using mod_perl, you must answer yes here. Otherwise the default is ok.
setuid stuff??? (Author doesn't use setuid.)
- make
- make test
- make install
Now you have perl 5.8.3 installed. I'll assume you followed my advice and installed it in /usr/local/perl-5.8.3.
Next step is to install all the RT depencies into that new perl.
(Alternatively, you might like to try my perl installation guide: http://use.perl.org/~jdavidb/journal/6477 . (Slightly dated, but I still use it through 5.8.7.) For RT, I recommend having a separate installation of perl owned by the same UNIX user that owns RT. But it's been awhile since I did this, since I now just use precompiled packages for RT.)
Part II: Installing RT requirements
RT can install them for you.
cd /your/RT/build/dir /usr/local/perl-5.8.3/bin/perl sbin/rt-test-dependencies --with-<databasename> --with-<web-environment> --install
Or use the CPAN shell.
/usr/local/perl-5.8.3/bin/perl -MCPAN -eshell cpan> install Required::Module cpan> quit /usr/local/perl-5.8.3/bin/perl sbin/rt-test-dependencies --with-<databasename> --with-<web-environment>
Now your perl 5.8.3 is installed and has all the modules needed to run RT. Notice that until now your current perl installation has not been disturbed.
Now you need to make sure your web server can use that perl.
Part III: Adapting your web server
Fast-CGI
Since Fast-CGI doesn't need to know anything special about your perl version, there is nothing special to do here.
mod_perl
You MUST rebuild mod_perl when upgrade perl. Official reason.
mod_perl2 works fine as DSO what makes easier to use mod_perl2 from distributor instead of compiling own version. mod_perl2 installation guide.
If mod_perl is compiled as DSO then you don't need rebuild Apache.
# if output from next shell command is empty then you use DSO in other case static. httpd -l | grep 'mod_perl'
SPECIAL NOTE FOR APACHE 1.x USERS, PLEASE DON'T SKIP THIS:
- If you use Apache1.x+mod_perl1.x then you want mod_perl compiled static with Apache.
- If you still have question "Why?" then you must read:
- Do you still have questions about DSO in Apache 1.x? You don't know how to build static mod_perl? It's not a big deal:
See also: ManualApache
Part IV: Finding perl new perl binary
Now the only problem left is that if you type 'perl' on the command line, your old perl will still be picked up and used. That means that the RT perl programs (rt-mailgate, mason-handler.fcgi) will still run using your old perl.