Preferred Perl version for 4.0.x?

RT Users
1

Does anyone know what version of Perl RT 4.x prefers?

I worked out a good recipe for installing RT 3.x on Mac OS X Server
10.6 which involved giving RT it’s own copy of perl 5.8.9, built
exactly the way RT wants.

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.

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.

I’m about to build a new server based on 10.7 (Lion) and plan on
bringing up a fresh RT instance – since I’m giving RT a private
Perl, would like to give it exactly what it wants.

If anyone wants it, I’ll post the recipe once I get the server back on line.

Thanks,

-Steve

2

I worked out a good recipe for installing RT 3.x on Mac OS X Server
10.6 which involved giving RT it’s own copy of perl 5.8.9, built
exactly the way RT wants.

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.

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.

I’m about to build a new server based on 10.7 (Lion) and plan on
bringing up a fresh RT instance – since I’m giving RT a private
Perl, would like to give it exactly what it wants.

If anyone wants it, I’ll post the recipe once I get the server back on line.

As far as I know, RT will pass tests on 5.8.3 or greater, but you’ll
almost certainly have a better toolchain experience if you use 5.12.3 or 5.14.2.
We’ve deployed RT for clients against custom built 5.12.3 and 5.14.2
without issue (including on OS-X server).

-kevin

3

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.

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” :slight_smile:

I agree that there ought to be a way to restore the system Perl back
to what was shipped/qualified.

I’m about to build a new server based on 10.7 (Lion) and plan on
bringing up a fresh RT instance – since I’m giving RT a private
Perl, would like to give it exactly what it wants.

If anyone wants it, I’ll post the recipe once I get the server back on line.

As far as I know, RT will pass tests on 5.8.3 or greater, but you’ll
almost certainly have a better toolchain experience if you use
5.12.3 or 5.14.2.

That’s the answer I was looking for.

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.

Thanks,

-Steve

rm ./config.sh # prevent crud from accumulating
export SDK=/Developer/SDKs/MacOSX10.6.sdk
./Configure -ds -e -Dprefix=/usr/local/perl-5.8.9-rt -Dman3ext=3pm
-Duseshrplib -Dinc_version_list=none
-Dusedtrace
-Dcc=gcc-4.2
-Accflags=“-arch x86_64 -pipe -nostdinc
-B$SDK/usr/include/gcc
-B$SDK/usr/lib/gcc
-isystem$SDK/usr/include
-F$SDK/System/Library/Frameworks”
-Acppflags=“-arch x86_64 -pipe”
-Aldflags=“-arch x86_64 -Wl,-syslibroot,$SDK”
-Alddlflags=“-arch x86_64
-bundle -undefined dynamic_lookup -L/usr/local/lib”

sudo mkdir -p /usr/local/lib # shut up warnings if it doesn’t exist
./build
make
make test
sudo make install

4

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” :slight_smile:

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