Good news, I have gathered enough information about being a pumpkin to
release the first snapshot of what will become 5.005_04.
Note: 5.8.2 is latest, 5.6.2 is stable, 5.005_03 is old. 5.005_04 is
just for compilation fixes.
If you're terribly impatient, you can fetch it now at:
http://astray.com/tmp/perl5.005_03-MAINT21792.tar.gz
However, it'll soon be up on CPAN at:
http://www.cpan.org/authors/id/L/LB/LBROCARD/perl5.005_03-MAINT21792.tar.gz
There have been a couple of patches since 5.005_03. The full
changelist is attached. This release should work fine under modern
Linuxes, with no other platforms really tested. Feedback for all
platforms is very welcome.
Filename: perl5.005_03-MAINT21792.tar.gz
Size: 3736930 bytes (3.6M, how titchy compared to bleadperl!)
MD5: 2075172b66ee414f984d6ed687135804
No amusing poems with this one, sorry, Leon
--
Leon Brocard.............................http://www.astray.com/
scribot.................................http://www.scribot.com/
... Barium: what you do with dead chemists
Doesn't build on FreeBSD (4.x) because Configure is still trying to use nm.
Rafael integrated a lot (all?) of the hints file changes from 5.8 to 5.6.2 -
I think it would be worth integrating all hints changes onwards from 5.6.2
to 5.005_04. I tried to do this in my p4 repository, but I didn't get it
right, so I can't tell you the p4 magic. (eg change 21455)
Hopefully someone else can.
Nicholas Clark
Yes, all. cp blead/hints/*.sh maint-5.6.2/hints
However some more Configure hacking may be necessary.
p4 changes -l //depot/maint-5.6/perl-5.6.2/Configure should list the
changes I made to it ; I remember fixes for FreeBSD, AIX 5 and OpenUNIX
going there.
1. The top-level Makefile (and makefile) has a dependency on pad.c and
pad.h, neither of which are present in the tarball. The lack of pad.c
aborts the build. No patch b/c I don't know whether to add pad.c or remove
it from *akefile. Fatal error. Removing the references to pad.* from the
two makefiles lets my compilations proceed quite nicely.
2. Ditto the above for reentr.c, utf8.c, utf8.h and xsutils.c.
3. MANIFEST mentions perl_exp.SH, which does not exist. Nonfatal.
Now, we are kind of a funky platform. So just perhaps these are my
fault....but I'm kind of curious to know why the Linux build doesn't see
these files as missing.
I hope to provide the necessary patches to get this old version to work on
VOS. We actually had a request for this version not too long ago (sigh).
Thanks
PG
--
Paul Green, Senior Technical Consultant,
Stratus Technologies, Maynard, MA USA
Voice: +1 978-461-7557; FAX: +1 978-461-3610
Would you accept a patch adding support for "modern" Configure flags
-Dmksymlinks, -Dversiononly, -Dusedevel?
> Would you accept a patch adding support for "modern" Configure flags
> -Dmksymlinks, -Dversiononly, -Dusedevel?
I'm afraid not, no.
Compiler / library / OS fixes only for 5.005_04.
We'll see about what happens after that, errrr, after that.
Is this something you're really interested in seeing?
Leon
--
Leon Brocard.............................http://www.astray.com/
scribot.................................http://www.scribot.com/
... Networks never lie
-Dmksymlinks because that's how I usually build perl,
-Dversiononly to conveniently install 5.5.4 along with other versions,
-Dusedevel because it's a short way to say -Uinstallusrbinperl -Dversiononly
Will you change installusrbinperl to default to n if /usr/bin/perl already
exists, as newer perls do?
> -Dmksymlinks because that's how I usually build perl,
> -Dversiononly to conveniently install 5.5.4 along with other versions,
> -Dusedevel because it's a short way to say -Uinstallusrbinperl -Dversiononly
>
> Will you change installusrbinperl to default to n if /usr/bin/perl already
> exists, as newer perls do?
I'm really going to be quite strict about this, I'm afraid.
-Dmksymlinks seems unecessary as not many people will build perl
outside the untarred directory. In fact, this only seems useful for
development of 5.005_04, which nobody should be doing, so I won't
accept patches for this.
-Dversiononly also seems uneccessary - most people build perls into
seperate directories. However, I will accept a patch to do this as we
don't necessarily want to blow away people's perls.
-Dusedevel I won't accept patches for (hey, there won't be a
development version)
However, in the spirit of not blowing away the installed perl with a
much much older one, I think changing installusrbinperl to default to
n if /usr/bin/perl already exists does seem sensible. I will accept a
patch which does this.
However, I'm now going on holiday for three weeks so patch applying
will have to wait.
Merry Christmas, Leon
--
Leon Brocard.............................http://www.astray.com/
scribot.................................http://www.scribot.com/
... ERROR 103: Dead mouse in hard drive.
Good.
>
>-Dmksymlinks seems unecessary as not many people will build perl
>outside the untarred directory. In fact, this only seems useful for
>development of 5.005_04, which nobody should be doing, so I won't
>accept patches for this.
It is useful to use one source tree and build binaries
for Win32, Solaris, Linux, FreeBSD, HPUX, ...