FAQ
I'm part of the XMLTV project that provides tools to collect and manage TV
listings data.

For years, I've generated a Windows EXE release using a very old version of
ActivePerl and their PerlApp product so the many non-technical users don't
have to mess with a complicated module environment.

I tried building XMLTV on ActivePerl again but I've not yet been
successful. I remember it was very difficult last time getting some of the
modules to work.

I tried building XMLTV using Strawberry Perl and it was extremely easy!
Great job guys! I've even added instructions to the XMLTV wiki so others
could do it.

I would still like to make a XMLTV.EXE for people, but PerlApp+Strawberry
Perl failed because a bunch of GCC DLLs were not included.

There are multiple version of Strawberry Perl... could one be statically
linked?

I've looked through the list archives and google searches, but don't see
any Strawberry+PerlApp success stories.

Robert

Search Discussions

  • Sisyphus1 at Jun 23, 2014 at 12:26 am
    From: Robert Eden
    Sent: Monday, June 23, 2014 4:20 AM

    Hi Robert,
    I've looked through the list archives and google searches, but don't see
    any Strawberry+PerlApp success stories.
    An alternative would be to install Par::Packer and use its pp utility to
    create the exe.

    I believe that 'pp' provides, among other things, an option that enables you
    to pack in any modules/dlls that don't get picked up automatically.

    Cheers,
    Rob
  • Robert Eden at Jun 23, 2014 at 2:36 am

    On 6/22/2014 7:26 PM, sisyphus1@optusnet.com.au wrote:
    I've looked through the list archives and google searches, but don't
    see any Strawberry+PerlApp success stories.
    An alternative would be to install Par::Packer and use its pp utility
    to create the exe.

    I believe that 'pp' provides, among other things, an option that
    enables you to pack in any modules/dlls that don't get picked up
    automatically.
    Thanks, but I looked into PP (and Perl2EXE) a few years ago and that
    migration turned out to be very difficult. I use some special features
    of PerlApp to have a single EXE that can execute any of the 20 or so
    XMLTV scripts.

    I think they way I got ActivePerl working before was a hodgepodge of
    modules compiled via cygwin and others. I'm hoping to avoid that. Is
    there any documentation on compiling my own version of Strawberry? I
    don't see any source code mentioned on the web page.

    Robert
  • Gabor Szabo at Jun 23, 2014 at 3:10 am

    On Mon, Jun 23, 2014 at 5:34 AM, Robert Eden wrote:

    Is there any documentation on compiling my own version of Strawberry? I
    don't see any source code mentioned on the web page.
    I never tried to build Strawberry myself, but as far as I know, you need
    this:

    https://metacpan.org/release/Perl-Dist-Strawberry

    Gabor
  • Sisyphus1 at Jun 23, 2014 at 10:48 am
    -----Original Message-----
    From: Robert Eden
    Is there any documentation on compiling my own version of Strawberry? I
    don't see any source code mentioned on the web page.
    Well - you could just build your own perl from source using (say) the
    compiler and dmake that shipped with Strawberry.

    You just grab the official perl 5.20.0 source, put your strawberry/c/bin
    folder at the beginning of the PATH, edit the (largely self-documenting)
    win32/makefile.mk appropriately, then cd to that win32 folder and run:
    dmake
    dmake test
    dmake install

    Attached is the win32/makefile.mk I've just used to build a 64-bit static
    perl-5.20.0 using Strawberry Perl-5.20.0 compiler (64-bit gcc-4.8.2).

    It installs perl into C:\_64\static_perl520_482. (Amend it if you want to
    install perl elsewhere.)
    It specifies that the compiler is in C:\_64\strawberry5.20.0\c (Amend that
    if it's not correct.)
    And it specifies an EXTRALIBDIRS setting that's incorrect for you. You'll
    want to set it to something like:

    EXTRALIBDIRS *= C:\_64\strawberry5.20.0\c\x86_64-w64-mingw32\lib
    C:\_64\strawberry5.20.0\c\lib\gcc\x86_64-w64-mingw32\4.8.2

    (depending upon where those folders actually are on your machine).

    Apart from that, it should be right to go for you.
    There were a few (three, I think) test script failures during 'dmake test'
    .... nothing to worry about.

    It seems to install dynamic perl.exe, perl5.20.0.exe and wperl.exe (and
    perl520.dll) along with a (large) static perl executable called
    perl-static.exe.
    So it's the perl-static.exe you'll want to be using.
    I've no idea what sort of mileage you'll get out of that ;-)

    And, of course, FAIK, there could already be a static Strawberry perl
    available somewhere (or kmx might even be busy building one for you right
    now.)

    Cheers,
    Rob
  • Robert Eden at Jun 23, 2014 at 2:58 pm

    On 6/23/2014 5:47 AM, sisyphus1@optusnet.com.au wrote:
    -----Original Message----- From: Robert Eden
    Is there any documentation on compiling my own version of
    Strawberry? I don't see any source code mentioned on the web page.
    Well - you could just build your own perl from source using (say) the
    compiler and dmake that shipped with Strawberry.

    You just grab the official perl 5.20.0 source, put your
    strawberry/c/bin folder at the beginning of the PATH, edit the
    (largely self-documenting) win32/makefile.mk appropriately, then cd to
    that win32 folder and run:
    dmake
    dmake test
    dmake install
    That should work! I'll let the list know how it goes (and if it works
    with PerlApp)

    Robert
  • Sisyphus1 at Jun 23, 2014 at 3:10 pm
    -----Original Message-----
    From: Robert Eden
    That should work! I'll let the list know how it goes (and if it works
    with PerlApp)
    Yes, please do - that would be interesting.

    Cheers,
    Rob
  • Octavian Rasnita at Jun 23, 2014 at 3:57 pm
    From: "Robert Eden" <rmeden@gmail.com>
    Subject: Re: statically linked Strawberry Perl for use with PerlApp?

    On 6/23/2014 5:47 AM, sisyphus1@optusnet.com.au wrote:
    -----Original Message----- From: Robert Eden
    Is there any documentation on compiling my own version of Strawberry? I
    don't see any source code mentioned on the web page.
    Well - you could just build your own perl from source using (say) the
    compiler and dmake that shipped with Strawberry.

    You just grab the official perl 5.20.0 source, put your strawberry/c/bin
    folder at the beginning of the PATH, edit the (largely self-documenting)
    win32/makefile.mk appropriately, then cd to that win32 folder and run:
    dmake
    dmake test
    dmake install
    That should work! I'll let the list know how it goes (and if it works
    with PerlApp)

    Robert

    I knew that PDK programs require ActivePerl. Hopefully I am not right, but
    if I am, StrawberryPerl may need to pretend it is ActivePerl, and I don't
    know if this is legal.

    I know that some newer versions of ActivePerl can't work with older versions
    of PDK, but a PDK upgrade is required, so there are some restrictions,
    probably for commercial reasons.

    In some cases other solutions than perlapp (PAR or perl2exe) are simply not
    working. If is the case of XMLTV also, writing on ActivePerl mailing list
    and asking for adding some modules and libs in ActivePerl can be a solution,
    at least for the future.

    Octavian
  • Kmx at Jun 23, 2014 at 10:09 pm

    On 23.6.2014 16:56, Robert Eden wrote:
    On 6/23/2014 5:47 AM, sisyphus1@optusnet.com.au wrote:
    -----Original Message----- From: Robert Eden
    Is there any documentation on compiling my own version of Strawberry?
    I don't see any source code mentioned on the web page.
    Well - you could just build your own perl from source using (say) the
    compiler and dmake that shipped with Strawberry.

    You just grab the official perl 5.20.0 source, put your strawberry/c/bin
    folder at the beginning of the PATH, edit the (largely self-documenting)
    win32/makefile.mk appropriately, then cd to that win32 folder and run:
    dmake
    dmake test
    dmake install
    That should work! I'll let the list know how it goes (and if it works
    with PerlApp)
    Just keep in mind that you probably do not want "static perl" you probably
    just want to use "-static-libgcc -static-libstdc++" compiler flags (which
    might introduce another unwanted side effects).

    Try to run dmake like this:
    dmake "BUILDOPTEXTRA=-static-libgcc -static-libstdc++"

    I have not tried it, this is just my guess.

    As Gabor mentioned if you want to try to build your custom Strawberry Perl
    start here:
    https://metacpan.org/pod/distribution/Perl-Dist-Strawberry/script/perldist_strawberry

    --
    kmx
  • Sisyphus1 at Jun 24, 2014 at 1:13 am
    -----Original Message-----
    From: kmx

    Try to run dmake like this:
    dmake "BUILDOPTEXTRA=-static-libgcc -static-libstdc++"
    I wonder ... is a perl built with that option binary-compatible with a perl
    that wasn't built with that option ?

    Nothing to do with this thread, but if they *are* binary-compatible, then I
    see here a way of creating PPM packages that don't have a dependency on
    those 2 dlls.

    No big deal, either way - just curious.
    And like you point out, there may be other side-effects ....

    Cheers,
    Rob
  • Octavian Rasnita at Jun 23, 2014 at 4:32 pm
    From: <sisyphus1@optusnet.com.au>
    -----Original Message-----
    From: Robert Eden
    Is there any documentation on compiling my own version of Strawberry? I
    don't see any source code mentioned on the web page.
    Well - you could just build your own perl from source using (say) the
    compiler and dmake that shipped with Strawberry.

    You just grab the official perl 5.20.0 source, put your strawberry/c/bin
    folder at the beginning of the PATH, edit the (largely self-documenting)
    win32/makefile.mk appropriately, then cd to that win32 folder and run:
    dmake
    dmake test
    dmake install

    Attached is the win32/makefile.mk I've just used to build a 64-bit static
    perl-5.20.0 using Strawberry Perl-5.20.0 compiler (64-bit gcc-4.8.2).

    It installs perl into C:\_64\static_perl520_482. (Amend it if you want to
    install perl elsewhere.)
    It specifies that the compiler is in C:\_64\strawberry5.20.0\c (Amend that
    if it's not correct.)
    And it specifies an EXTRALIBDIRS setting that's incorrect for you. You'll
    want to set it to something like:

    EXTRALIBDIRS *= C:\_64\strawberry5.20.0\c\x86_64-w64-mingw32\lib
    C:\_64\strawberry5.20.0\c\lib\gcc\x86_64-w64-mingw32\4.8.2

    (depending upon where those folders actually are on your machine).

    Apart from that, it should be right to go for you.
    There were a few (three, I think) test script failures during 'dmake test'
    .... nothing to worry about.

    It seems to install dynamic perl.exe, perl5.20.0.exe and wperl.exe (and
    perl520.dll) along with a (large) static perl executable called
    perl-static.exe.
    So it's the perl-static.exe you'll want to be using.
    I've no idea what sort of mileage you'll get out of that ;-)

    And, of course, FAIK, there could already be a static Strawberry perl
    available somewhere (or kmx might even be busy building one for you right
    now.)

    Cheers,
    Rob

    Do you know if that static Perl can be used if the entire directory is moved
    on another path?

    Octavian
  • Sisyphus1 at Jun 24, 2014 at 1:03 am
    -----Original Message-----
    From: Octavian Rasnita
    Sent: Tuesday, June 24, 2014 2:28 AM

    Do you know if that static Perl can be used if the entire directory is
    moved on another path?
    Seems ok to me after I moved it:

    C:\Windows\System32>perl-static -le "print $^X;print for @INC"
    C:\_64\moved\static_perl520_482\bin\perl-static.exe
    C:/_64/moved/static_perl520_482/site/lib
    C:/_64/moved/static_perl520_482/lib
    .

    Is that what you meant ?

    There are, of course, then a number of incorrect Config settings - eg:

    C:\Windows\System32>perl-static -MConfig -le "print $Config{installbin}"
    c:\_64\static_perl520_482\bin

    but that's no different to any other perl that gets moved.

    The static-perl.exe does have a runtime dependency upon libgcc_s_sjlj-1.dll
    and libstdc++-6.dll - hence kmx's recommendation that perl be built with
    "-static-libgcc -static-libstdc++" (which I haven't tried).

    Cheers,
    Rob
  • Octavian Rasnita at Jun 24, 2014 at 7:34 pm
    From: <sisyphus1@optusnet.com.au>
    -----Original Message-----
    From: Octavian Rasnita
    Sent: Tuesday, June 24, 2014 2:28 AM

    Do you know if that static Perl can be used if the entire directory is
    moved on another path?
    Seems ok to me after I moved it:

    C:\Windows\System32>perl-static -le "print $^X;print for @INC"
    C:\_64\moved\static_perl520_482\bin\perl-static.exe
    C:/_64/moved/static_perl520_482/site/lib
    C:/_64/moved/static_perl520_482/lib
    .

    Is that what you meant ?


    I am thinking that if Perl would work even if it is moved into another
    directory, it can be used for deploying applications by including the whole
    Perl + installed modules instead of using perlapp/PAR/perl2exe/Cava
    Packager.

    If Perl needs to be installed by each user on the target computer, than it
    is not a solution for most Windows users.
    PDK is not free and all other solutions for packaging have some issues and
    don't work in all the cases, so beeing able to deploy Perl together with
    some programs would be great.

    I don't know C and Perl's internals, so I don't know why the directory in
    which Perl runs is so important.

    Octavian
  • Robert Eden at Jun 25, 2014 at 4:40 am
    Status Update:

    I switched to development on a virtual machine to avoid settings
    conflicts with my main computers and to allow easy reverts.

    I'm able to build my own Strawberry! I am using the -static-libgcc
    -static-libstdc++ switches ( I think that's what I need), but with
    Strawberry, other switches seem to be turned on that negate those
    switches (-shared-libgcc comes to mind). I need to see where that's
    set. Of course each test takes a few hours! :)

    I'm also trying to build a standard perl using the Strawberry setup... I
    ran into problems with some modules, but that may be have been due to
    conflicts on my main computer. I haven't tried it in the Virt yet.

    Unfortunately, life has been busy so I haven't had that much time to
    play, but I wanted to give you guys an update.

    The Strawberry build process is amazing.. great job guys!

    Robert
  • Robert Eden at Aug 6, 2014 at 5:52 am
    Sorry for the slow response, but family summer activities have slowed
    things down more than expected. (on the contrary, I figured it would allow
    for more time!)

    Anyway, I got it to work!

    The suggestion

             BUILDOPTEXTRA=-static-libgcc -static-libstdc++

    Was close, but it seems those options only affect the compile phase, not
    the linking.

    My solution was to modify Perl's Makefile.mk
    old: LINK_FLAGS = $(LINK_DBG) -L"$(INST_COREDIR)" -L"$(CCLIBDIR)"
    new: LINK_FLAGS = $(LINK_DBG) -L"$(INST_COREDIR)" -L"$(CCLIBDIR)"
    -static-libgcc -static-libstdc++ -static -lpthread

    Of course I did it the Strawberry way...
         create a modified version of Makefile.mk as win32_Makefile.mk
         create my own Eden.PP build script



    BUILDOPTEXTRA=-static-libgcc
    -static-libstdc++"BUILDOPTEXTRA=-static-libgcc -static-libstdc++"
    BUILDOPTEXTRA=-static-libgcc -static-libstdc++"
    BUILDOPTEXTRA=-static-libgcc -static-libstdc++"
    BUILDOPTEXTRA=-static-libgcc -static-libstdc++"



  • Robert Eden at Aug 6, 2014 at 5:55 am
    (oops.. gmail web client sent it before I was ready.. should have used
    TBird!)

    Sorry for the slow response, but family summer activities have slowed
    things down more than expected. (on the contrary, I figured it would allow
    for more time!)

    Anyway, I got it to work!

    The suggestion

             BUILDOPTEXTRA=-static-libgcc -static-libstdc++

    Was close, but it seems those options only affect the compile phase, not
    the linking.

    My solution was to modify Perl's Makefile.mk
    old: LINK_FLAGS = $(LINK_DBG) -L"$(INST_COREDIR)" -L"$(CCLIBDIR)"
    new: LINK_FLAGS = $(LINK_DBG) -L"$(INST_COREDIR)" -L"$(CCLIBDIR)"
    -static-libgcc -static-libstdc++ -static -lpthread

    Of course I did it the Strawberry way...
         create a modified version of Makefile.mk as win32_Makefile.mk
         create my own Eden.PP build script
         use the patch method to replace the Makefile as the build progresses.

    Once that was built and installed, I added "C:\strawberry\perl\bin" to my
    path, PerlApp found it and the resulting executable worked fine on a system
    without GCC or other programs!

    Thanks a lot for you guys' help and a great product!

    Robert



    On Wed, Aug 6, 2014 at 12:52 AM, Robert Eden wrote:

    Sorry for the slow response, but family summer activities have slowed
    things down more than expected. (on the contrary, I figured it would allow
    for more time!)

    Anyway, I got it to work!

    The suggestion

    BUILDOPTEXTRA=-static-libgcc -static-libstdc++

    Was close, but it seems those options only affect the compile phase, not
    the linking.

    My solution was to modify Perl's Makefile.mk
    old: LINK_FLAGS = $(LINK_DBG) -L"$(INST_COREDIR)" -L"$(CCLIBDIR)"
    new: LINK_FLAGS = $(LINK_DBG) -L"$(INST_COREDIR)" -L"$(CCLIBDIR)"
    -static-libgcc -static-libstdc++ -static -lpthread

    Of course I did it the Strawberry way...
    create a modified version of Makefile.mk as win32_Makefile.mk
    create my own Eden.PP build script



    BUILDOPTEXTRA=-static-libgcc -static-libstdc++"BUILDOPTEXTRA=-static-libgcc -static-libstdc++"
    BUILDOPTEXTRA=-static-libgcc -static-libstdc++"
    BUILDOPTEXTRA=-static-libgcc -static-libstdc++"

    BUILDOPTEXTRA=-static-libgcc -static-libstdc++"


Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupwin32-vanilla @
categoriesperl
postedJun 22, '14 at 6:20p
activeAug 6, '14 at 5:55a
posts16
users5
websitestrawberryperl.com

People

Translate

site design / logo © 2019 Grokbase