statically linked Strawberry Perl for use with PerlApp?

[Robert Eden]

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

[sisy...@optusnet.com.au]

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]

On 6/22/2014 7:26 PM, sisy...@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]

On Mon, Jun 23, 2014 at 5:34 AM, Robert Eden <rme...@gmail.com> 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

[Robert Eden]

On 6/23/2014 5:47 AM, sisy...@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

[sisy...@optusnet.com.au]

Yes, please do - that would be interesting.

Cheers,
Rob

[Octavian Rasnita]

From: "Robert Eden" <rme...@gmail.com>
Subject: Re: statically linked Strawberry Perl for use with PerlApp?

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

[Octavian Rasnita]

From: <sisy...@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

[kmx]

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

[sisy...@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 ?

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

[sisy...@optusnet.com.au]

-----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]

From: <sisy...@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]

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]

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]

(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