in reply to Re: Compiling modules for win32 ActivePerl
in thread Compiling modules for win32 ActivePerl

Still, not all is OK. Some modules seem to need a tool called dlltool which is missing and I haven't yet been able to find and install it.

You need binutils.

<rant>

strawberry perl is fantastic, but it still too disjointed from msys/mingw, which is too disjointed from gnuwin32. They all have similar goals, and need to cooperate more easily with each other.

For example perl won't build with sh Configure under msys, so msys is stuck at perl5.6.1. Strawberry perl developers helped craft a dmake specific makefile to compile perl with mingw, but now it doesn't come with sh, so every module which builds easily under linux with sh configure needs special steps for win32. Even ExtUtils::MakeMaker (and related modules) needed special tweaks.

Instead of msys sh configure being a familiar unifying interface, or gnuwin32 providing the latest binaries (lots are outdated), everything from zlib to libtiff to imagemagick to Image::Magick needs special steps.

Strawberry perl hopes it is A 100% Open Source Perl for Windows that is exactly the same as Perl everywhere else but without GNU build system it falls short.

They could all learn some things from http://portableapps.com/

</rant>

Sorry about the small rant, dlltool comes with binutils.

Replies are listed 'Best First'.
Re^3: Compiling modules for win32 ActivePerl
by DrHyde (Prior) on Sep 30, 2009 at 09:46 UTC

    I'm not sure what you're getting at. Problems building perl are of no consequence for a Strawberry user because Strawberry provides a binary. And modules that you build with 'sh configure'? Huh? I've never come across anything like that. The CPAN standard way is either 'perl Makefile.PL' or 'perl Build.PL'.

    As for portableapps.com - that appears to be a tool for carrying your Windows programs around from one Windows machine to another. Strawberry perl, on the other hand, is an attempt to get a primarily Unixy program (perl) to run on Windows.

[reply]
      I'm not sure what you're getting at. Problems building perl are of no consequence for a Strawberry user because Strawberry provides a binary.

      Like I said, they're all too disjointed , and need to cooperate more easily with each other. Compiling perl is one example. It matters because strawberry doesn't provide 5.10.1 yet, and it doesn't provide blead.

      And modules that you build with 'sh configure'? Huh? I've never come across anything like that. The CPAN standard way is either 'perl Makefile.PL' or 'perl Build.PL'.

      Look in the Alien:: namespace (or different versions of Math::Pari). Without sh it gets complicated for no reason.

[reply]

        Are you aware that porting stuff to work properly on strange platforms like Windows is Hard? And that the people doing it are volunteers? I'm sure there's lots of stuff that the Strawberry farmers would like to do to improve things, but there's nothing that they *need to* do.

        Alien::* and its ilk is always gonna be weird. They'll also fail on VMS and on platforms which have the "wrong" shell. I suggest you submit bug reports and patches.

[reply]

In Section Seekers of Perl Wisdom