Stories
Slash Boxes
Comments

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Sunday December 23, 2007
05:55 AM

Strawberry Perl 5.10.0 Released!

[ #35193 ]

http://strawberryperl.com/download/strawberry-perl-5.10.0-final.exe

After over a year since the last release, it is with equal parts of pride and relief that I present Strawberry Perl 5.10, the next major release of the Vanilla Perl Project's flagship Perl distribution.

This release represents the beginning of the third generation of release code.

The first generation was a simple build script, and was used to create the original Vanilla Perl distribution.

The second generation moved from a simple script to a config-driven model with Perl::Dist::Builder, and gave us the original Strawberry Perl.

The new Perl::Dist::Inno takes this beyond simple configuration and provides a complete object heirachy for modelling and compiling Win32 Perl distributions.

So now not only can you replicate Strawberry Perl yourself, you can literally sub-class Strawberry Perl and build your own custom distributions in as little as 10 lines of code.

This release also sees more attention paid to Strawberry Perl's CPAN capabilities, and in particular to its out-of-the-box functionality.

The new CPAN client setup is completely zero-configuration, with CPAN::SQLite pre-installed for reduced memory consumption and a http://cpan.strawberryperl.com/ redirector, so that we can keep zero-conf users pointing at a good default repository and collect statistics on the CPAN modules that Win32 users care about the most.

We've also added some little touches like a pointing the "Strawberry Perl Website" link that goes to a release-specific page, so we can update with errata and so on.

On the module side things remain much the same. We retain the previous model of bundling a large number of toolchain and CPAN-related modules, but don't bundle modules that add general functionality.

For people that would like more modules pre-installed, stay tuned for information on the long-awaited "Chocolate Perl" distribution.

Errata:

While the new releases is stable and very usable, it lacks in a few areas we will be addressing in the next release cycle.

1. Relocation

The new "relocatable" magic for Perl 5.10 is implemented as an optional Configure parameter. Win32 Perl releases do NOT, unfortunately, use Configure.

As such, relocation will not be available in this release cycle of Strawberry Perl. I hope to investigate workarounds for this problem at a later date.

2. Windows Vista

The MinGW compiler system has known problems on Vista with the current directory setup, and as such Strawberry Perl does not support Vista at this time.

I have some ideas on how to fix this, but don't want to potentially burdon non-Vista users with the complications it might create.

So we may well see a specific Vista version released separately.

HOWEVER, minus those few issues, I'm very happy with the quality of the new release, and look forward to increased sleep and some time off.

Enjoy.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Strawberry Perl 5.10.0 Released! 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Great work!!
    I've installed.
    But cpan gives following error message.

    -------------------------------------------------
    C:\strawberry>cpan
    CPAN: File::HomeDir loaded ok (v0.67)

    cpan shell -- CPAN exploration and modules installation (v1.9205)
    ReadLine support enabled

    cpan> r
    DBD::SQLite::db prepare failed: no such table: dists(1) at dbdimp.c line 271 at
    C:\strawberry\perl\site\lib/CPAN/SQLite/DBI/Search.pm line 86, line 3.
    Catching error: 'DBD::SQLite::db prepare failed: no such table: dists(1) at dbdi
    mp.c line
    • After initializing by "cpandb --setup" command. then the problem disappeared. I wonder should I do this manually.
      • I'm surprised you had to do it at all! :(

        What setup do you have?
        • I didn't do anything after install. cpan cpan> reload index cpan> r also have no problem.
          • No, I mean what operating system, user permissions, etc...
            • I am using Korean Windows XP.

              Details of my envirionment from CPAN::Reporter says

              Perl special variables (and OS-specific diagnostics, for MSWin32):

                      $^X = C:\strawberry\perl\bin\perl.exe
                      $UID/$EUID = 0 / 0
                      $GID = 0
                      $EGID = 0
                      Win32::GetOSName = WinXP/.Net
                      Win32::GetOSVersion = Service Pack 2, 5, 1, 2600, 2, 2, 0, 256, 1
                   
  • many win user will complain that it install in root dir. i don't like that either. is it for purpose or accidental?
    • If you *have* to put it in the root directory (C:\whatever) I won't be using it. Is it really hardcoded to do that?
      • Unfortunately, due to some remaining issues with Perl on Win32, you have to at least have a path with no spaces in it.

        Since you can get the build code yourself, you can at least now generate your own installer that installs to the location that YOU want.
    • it also don't seems to remove its PATH entry after deinstal. this is a major point of suckiness that some installer have in common.
      • I found a hook in Inno Setup that MIGHT let me achieve the removal of the PATH entries... I'll have a shot at making it work in Update 1
    • like for instance the active state, if your installer is better on that, it's a real reason for me to switch
      • Unfortunately, there's nowhere in Inno Setup that you can hook that specific clean up functionality (or so it appears).

        I continue to look for a way to fix that.
  • I've just installed it on my Strawberry XP VM. I turned off use_sqlite because cpan was (I think) getting confused by something that a previous Strawberry left. It appears to work fine with use_sqlite disabled. I'm just doing a cpan upgrade now.
  • For some reason, it works fine on Vista for me. I had to set "$self->{XS_DEFINE_VERSION} = '';" to avoid a problem with XS_VERSION_BOOTCHECK, and I had to remove the backslashes in: $self->{DEFINE_VERSION} = '-D$(VERSION_MACRO)="$(VERSION)"'; . I just modified ExtUtils\MM_Any.pm directly to fix these two things, but I'm sure there's a better way using the OS-specific files in ExtUtils.

    Note that I have UAC disabled - I expect that disabling UAC whilst installing on Vista is a Good Thing.
    • I've previously done some testing on Vista Beta 1 and found things worked ok, but that was also with UAC turned off permanently.
  • Trolling google for MinGW/Vista I saw a post suggesting adding the bin path of cc1.exe to PATH. that got me futher along. but now Tk dies with a compile error and lots of warnings. Who do I report this to and how? Thanks
    --
    "If you were supposed to understand it, we wouldn't call it code." - FedEx
  • What really striked me is that you globally set TERM=dumb. This is imho a very bad thing, because it was interfering with my cygwin until I finally noticed where it was going from. I think setting global environment is a bad thing, it would be much better to provide a batch file that sets all necessary variables and then leaves command prompt. Users who need it globally will set it themselves and it won't unnecessarily clobber environment for others. Also, when will you publish Perl::Dist::Strawberry on cp
    • > Users who need it globally will set it themselves and it won't unnecessarily clobber environment for others.

      The entire concept of Strawberry is that there are no additional steps required to get it into a working state.

      The problem is that most people will NOT set TERM=dumb themselves, because most Windows uses aren't familiar with hacking things like the environment themselves.

      It falls back on universal education as a crutch.

      For cygwin users, you are already a step above the normal standard, and as a g
  • Also, I find it strange that your installer sets LIB to point to perl/bin instead of perl/lib/CORE (that's where libperl510.a is after all). Linker probably tries to link directly against .dll and succeeds, but I'm not sure if that's a really good thing.
  • Here's a script I'm using myself. I think it would be good if instead of changing global environment there would be a shortcut to such a batch file:

    @echo off
    set TERM=dumb
    set FTP_PASSIVE=1
    set PATH=C:\strawberry\c\bin;C:\strawberry\perl\bin;%PATH%
    set INCLUDE=C:\strawberry\c\include;C:\strawberry\perl\lib\CORE;%INCLUDE%
    set LIB=C:\strawberry\c\lib;C:\strawberry\perl\lib\CORE;%LIB%
    title Strawberry Perl Environment
    cmd /k
    • This sort of setup would break the normal "cmd" environment though right?

      It would mean that you could ONLY use Perl via that special shortcut?

  • Windows Vista: The MinGW compiler system has known problems on Vista with the current directory setup, and as such Strawberry Perl does not support Vista at this time. I have some ideas on how to fix this, but don't want to potentially burdon non-Vista users with the complications it might create. So we may well see a specific Vista version released separately.

    As you can read in this thread on Perlmonks [perlmonks.org], there is a patch available for MinGW's gcc on Vista. It is apparently enough to fix build issues on XS modules using MinGW on Vista, so I'm hopeful that it might be enough to fix Strawberry Perl too.

    If I read it correctly, the problem was in incorrect parameter passing to some functions, and Vista catches it. I'm quite sure these function calls are actually just as incorrect on previous versions of Windows... so I see no reason why a patched gcc wouldn't work

    • Addendum: This is the post [aarongiles.com] that gave me the latter idea:

      This is an actual mingw bug that has been tracked down to a change in the way the Microsoft standard C libraries handle invalid parameters. Older versions of the DLL would not check invalid parameters and go down potentially untested code paths with them. The versions in Vista do stricter parameter checking. Some calls made by the mingw tools pass invalid parameters to one of the functions and fail, causing the internal paths to quit working.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.