On Mon, 2003-06-16 at 22:34, Matt Sergeant wrote: > OK, from what I've heard from elsewhere Red Hat shipped a broken perl > with RH9 - a build from CVS. Why oh why do we have to put up with this > crap from Red Hat I don't know...
Doesn't surprise me...the TeX they ship is grotesquely out of date too. Given that the latest of both systems is always at CTAN and CPAN I just don't understand why they insist on doing this. Thanks for the hint. This is the first I'd heard of it. > Anyway, the best fix I can think of for you is to install a new perl in > a non-default location. If you run perl's configure it should use > /usr/local rather than Red Hat's /usr for the location of perl, so this Hold on, that conflicts. You say "install a new perl in a non-default location" (ie from what I understand, you mean *not* /usr/local) but you then go on to say it should be /usr/local, which *is* the default location...isn't it? > should work just fine for most scripts and leave your current Red Hat > perl intact. Perl always makes bin/perl a symlink to bin/perl<version> > anyway, so if it overwrites your bin/perl with a newer one you can > always restore the old link so your system scripts continue to function. OK, this is no problem, raw perl always seems to compile and install happily. It's getting the system to set @INC to the right places is the hard bit. Actually, impossible as far as I can see, as I cannot locate where @INC is defined. Anyone know? > So what you basically want to do is download perl 5.8.0 from perl.org > or perl.com or direct from cpan. Then compile and install that (it's > very straightforward - just run "sh Configure -de" after downloading it > and entering the new directory, then run "make", "make test" and "make > install" (last part as root) and it'll all "just work"). That all went fine. Just 2 errors: > lib/locale...........................Malformed UTF-8 character > (unexpected non-continuation byte 0x61, immediately after start byte > 0xe7) in pattern match (m//) at ../lib/locale.t line 526. > ok > lib/Locale/Codes/t/all...............Malformed UTF-8 character > (unexpected end of string) at ../lib/Locale/Language.pm line 115, > <DATA> line 109. > Malformed UTF-8 character (unexpected end of string) at > ../lib/Locale/Language.pm line 117, <DATA> line 109. > Malformed UTF-8 character (unexpected end of string) at > ../lib/Locale/Language.pm line 115, <DATA> line 178. > Malformed UTF-8 character (unexpected end of string) at > ../lib/Locale/Language.pm line 117, <DATA> line 178. > Malformed UTF-8 character (unexpected end of string) at > ../lib/Locale/Language.pm line 66. > Malformed UTF-8 character (unexpected end of string) at > ../lib/Locale/Language.pm line 66. > FAILED at test 9 > lib/Locale/Codes/t/constants.........ok > lib/Locale/Codes/t/country...........ok > lib/Locale/Codes/t/currency..........ok > lib/Locale/Codes/t/languages.........Malformed UTF-8 character > (unexpected end of string) at ../lib/Locale/Language.pm line 115, > <DATA> line 109. > Malformed UTF-8 character (unexpected end of string) at > ../lib/Locale/Language.pm line 117, <DATA> line 109. > Malformed UTF-8 character (unexpected end of string) at > ../lib/Locale/Language.pm line 115, <DATA> line 178. > Malformed UTF-8 character (unexpected end of string) at > ../lib/Locale/Language.pm line 117, <DATA> line 178. > FAILED at test 22 Something in the Perl 5.8.0 distro is hosed in the UTF-8 stuff but I suspect it's not critical, unless it really is directly related to the failure of iconv...which it might be... Installed it anyway. > Then you need > to build mod_perl-1.27 using this fresh perl, which should be installed > as /usr/local/bin/perl5.8.0. /usr/local/***bin***? Surely not. /usr/local/lib/perl5/5.8.0 is where Perl wanted to go, so I let it. Or did you mean install mod_perl at /usr/local/bin? Or what? > All sounds quite complex, but if you're careful to always use your > "newer" perl it should all fall into place quite happily. But I don't have any control over which perl gets used. I don't do perl, so I don't know how to tell existing and new systems to use the new one. Simply softlinking the new perl binary to /usr/local/bin isn't enough, nor is removing /usr/bin/perl, or adding to the PATH. It needs some kind of deep surgery to fix this silly @INC problem which always crops up. ///Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
