[sf-perl] upgrade hell?

[Bryan Beeley]

I have faced something like this several times.  I have always installed
new versions of of CPAN modules without trouble, or having to muck with
with any of the defaults for library paths.

However, if you have your libraries in a custom location, it might be
worth creating a new directory for the new modules, or moving the old
directory(ies?) aside, before you reinstall everything from CPAN (maybe
install the new modules in /nas/reg2).  I have always done this on
machines that have a default OS package install along with a custom
built Perl executable (usually built from source and installed in
/usr/local).  I would expect that using the default system Perl with a
custom directory for core libraries is more likely to cause trouble when
mixing versions.

Bryan

On 10/30/2012 06:32 PM, David Alban wrote:
> greetings,
>
> our sysadmins are turning out boxes now which run perl 5.10.1 whereas
> all of our tooling has long run on boxes running 5.8.8.  our tools
> that use non-core modules get errors like:
>
> /usr/bin/perl: symbol lookup error:
> /nas/reg/lib/perl/x86_64-linux-thread-multi/auto/Data/Dumper/Dumper.so:
> undefined symbol: Perl_Tstack_sp_ptr
>
> it appears that we have some choices.
>
> * downgrade the new boxes to 5.8.8
> * put 5.8.8 on /some/network/filesystem and change "#!/usr/bin/perl"
> to "#!/some/network/filesystem/bin/perl" in our tools
> * reinstall all of our cpan modules on the 5.10.1 boxes (well,
> actually on a nas.  the current ones are also on a nas.)
>
> poll:  have you faced this?  what did you do?  what worked / didn't work?
>
> old systems:
>
> This is perl, v5.8.8 built for x86_64-linux-thread-multi
> CentOS release 5.5 (Final)
> Linux somehost 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010
> x86_64 x86_64 x86_64 GNU/Linux
>
> new systems:
>
> This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi
> CentOS release 6.2 (Final)
> Linux someotherhost 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22
> GMT 2011 x86_64 x86_64 x86_64 GNU/Linux
>
> thanks,
> david