On Mon, Feb 13, 2012 at 02:30:17PM -0500, Steve Sisak wrote: > At 1:18 PM -0500 2/13/12, Kevin Falcone wrote: > > > RT 3.x won't compile on Perl 5.12 and wants Perl built > >> single-threaded and with other special options -- giving RT a > >> private Perl install to chew on works fine, however. The RT docs > >> don't seem to have been updated in a long time. > > > >I run RT 3.8 and 4.0 on 5.12.3 as my standard testing perl, on Lion > >and previously on Snow Leopard. It works fine. > > It's been awhile since I messed with this, but to be absolutely > specific, I was doing a migration of RT 3.4.4 to 3.8.3 and > discovered that 3.4.4 contained a bunch of calls deprecated in Perl > 5.12 and wouldn't pass tests until I backed off to Perl 5.8.9, so > this could have been fixed any time after 3.4.4.
RT 3.4.4 dates from 5 or 6 years before than 5.12 and 5.12 is documented to have added a number of new deprecation warnings. Even 3.6 releases have trouble working on 5.10 or modern CPAN modules, Having trouble with 3.4 on a modern perl isn't really indicative of problems with 4.0 on a modern perl. You'd have trouble running RT 3.8.8 on 5.12 or newer and I don't believe the 3.8 series gained complete 5.12 compliance until 3.8.11. 4.0.5 will work fine with 5.12.3 or 5.14.2 if you'd like the advantages of a modern supported perl release. > In any case, I'm planning on bringing up RT 4.0.5 this time and > happy to give it whatever Perl it's most happy with. > > > > Lion Server ships with 5.12.3, but running CPAN on Apple's default > >> Perl install can leave your server non-functional with no way to get > >> back w/o reinstalling the OS. > > > >That sounds like a fascinating Apple bug that I haven't encountered. > > Or you could call it a CPAN "feature" :-) I've been using the CPAN shell on OS-X for almost a decade now, with versions of perl from 5.6 up to 5.14 without ever leaving my machine non- functional. I've never run into trouble installing CPAN modules against /usr/bin/perl on OS-X, but I would never upgrade the version installed as /usr/bin/perl, and I've long preferred to use a sandboxed perl on many different operating systems. It's easier to test a clean install of RT and isolate problematic module versions that way. > >We've deployed RT for clients against custom built 5.12.3 and 5.14.2 > >without issue (including on OS-X server). > > Are there any special options you recommend? > > For reference, the Perl build commands I ended up with for building > into /usr/local/perl-5.8.9-rt on 10.6 are copied below as they may > be generally useful. I've never needed special options on OS-X, sh Configure -des -Dprefix=/opt/perl5123 has worked fine on every operating systems where I've built perl. These days I use perlbrew so I can easily switch between 6 installed versions of perl and I just let it use whatever default build switches it wants. If you run into trouble building perl on OS-X I'm sure it's something the perl5-porters mailing list would love to hear about. Also, I'm subscribed to the mailing list, there's no need to CC me on replies, I'll see your reply on the list. Thanks -kevin
pgpFaKOZXUjH7.pgp
Description: PGP signature
-------- RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 & 6, 2012
