$ uname -a
Linux lt-gm 2.6.16-8-smp #1 SMP Tue Mar 28 11:00:06 UTC 2006 i686 i686
+ i386 GNU/Linux
$ /home/shmem/comp/perl5.6.1/bin/perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuratio
+n:
  Platform:
    osname=linux, osvers=2.6.16-8-smp, archname=i686-linux
    uname='linux lt-gm 2.6.16-8-smp #1 smp tue mar 28 11:00:06 utc 200
+6 i686 i686 i386 gnulinux '
...
[download]

It does build. As does perl4.0.1.8 (patch level 36). Another question is whether it's sensible to use it.

What is a 'modern system' for you? I'm running OpenBSD 4, SuSE 10.1.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

I haven't tried; the reasoning I remember for Perl 5.6.2 was because it wouldn't build with a modern GCC, for example.

it wouldn't build with a modern GCC


D:\>perl -V:cc
cc='gcc';

D:\>perl -e "print $]"
5.006002
[download]

That is, of course, built using the MinGW port of gcc (version 3.2.x, I think). I also had a 5.6.1 built using the same compiler - but it has long been deleted.
Not sure that 3.2.x qualifies as "modern", ftm ...

Cheers,
Rob

$ gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr --w
+ith-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/s
+hare/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c
+,c++,objc,fortran,java,ada --enable-checking=release --with-gxx-inclu
+de-dir=/usr/include/c++/4.1.0 --enable-ssp --disable-libssp --enable-
+java-awt=gtk --enable-gtk-cairo --disable-libjava-multilib --with-sli
+bdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --
+enable-libstdcxx-allocator=new --without-system-libunwind --with-cpu=
+generic --host=i586-suse-linux
Thread model: posix
gcc version 4.1.0 (SUSE Linux)
[download]

Not modern enough? ;-)

But yes, gcc is a cranky beast. On some releases things appear to be broken which aren't. And, 5.6.1 didn't build "out of the box", I had to patch DB_File.xs due to a modern Berkeley DB version.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

I believe chromatic is speaking about Fedora/Redhat. IIRC They made some non-standard (at the time) changes to gcc, which caused many programs not to compile.

grep

1)Gain XP 2)??? 3)Profit

Rereading my original post, I guess it does appear whiny. I'm not stuck forever in this job with the perl 5.6.1, as I shall be moving on from the client site at the beginning of March. I'm using 5.8.8 for my home environments.

In terms of a base line perl version when developing CPAN modules, I have been choosing 5.6.1, as it includes our and lexical filehandles. In my CPAN modules, I've not been using any constructs that require 5.8.

I'm glad this thread has provoked discussion on the subject of support for old perl versions. Going forward, I think it would be useful for some guidelines for module authors, encouraging them to think about the following questions:

• What is the minimum perl version you are willing to support?

• What is the minimum perl version the module has been tested against?

• What is the perl version before which the module will definitely break?

With perl 5.10, or indeed perl 6, this topic will be bound to resurface.

Tough. Go fork it and maintain it yourself.

xoxo,
Andy