develooper Front page | perl.perl5.porters | Postings from June 2013

Re: dmake can't find config.h, and collector throws error when tryingto compile perl-static.exe (perl-5.18.0 / mingw / 32b)

Thread Previous | Thread Next
From:
Jan Dubois
Date:
June 6, 2013 16:32
Subject:
Re: dmake can't find config.h, and collector throws error when tryingto compile perl-static.exe (perl-5.18.0 / mingw / 32b)
Message ID:
CAD-TLz_y5zAs68jNZ4YynMyfu1x5U=OPZ6f9CrTviyFEUKJpOw@mail.gmail.com
On Thu, Jun 6, 2013 at 6:30 AM, Steve Hay <Steve.Hay@verosoftware.com> wrote:
> I thought I was all done then, but it still didn't work: my static
> perl.exe now complains that it can't find Win32::CopyFile(). And looking
> at the size of it I'm not very surprised: it's a good deal bigger than
> normal (about 2MB rather than 10kB), but nowhere near the size of the
> perl519s.lib (about 20MB) which it supposedly includes.
>
> The reason is presumably that when a linker pulls objects from a library
> to put into the binary that it is creating, it only takes those objects
> which contain symbols which are referenced somewhere; all other objects
> are discarded. I'm guessing that when building perl-static.exe, where
> are no references to Win32::CopyFile so even though an object containing
> that function is in perl519s.lib, it doesn't get put in perl-static.exe.

I don't quite understand this: you should have an xsinit function
somewhere that references boot_Win32, so everything should be pulled
in.

I don't understand the appeal of a statically linked Perl, so I don't
really know how it is being built, but I don't see a fundamental
reason why it shouldn't work, as long as you have references to all
the boot_* symbols in your main app or in a compilation unit that is
otherwise referenced from your main app.

Cheers,
-Jan

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About