Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 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.