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

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

Thread Previous | Thread Next
From:
Steve Hay
Date:
June 6, 2013 17:31
Subject:
RE: dmake can't find config.h, and collector throws error when trying to compile perl-static.exe (perl-5.18.0 / mingw / 32b)
Message ID:
67B2BB40A61BE846B65EF4793B863D6CBB1DA6@ukmail02.planit.group
Jan Dubois wrote on 2013-06-06:
> 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.
> 

Ok, that makes sense, so not nearly as drastic a problem as I had
thought then!

Running Win32.c through the preprocessor I see that we do, of course,
have a boot_Win32() function containing this:

    Perl_newXS(my_perl, "Win32::CopyFile",w32_CopyFile,file);

and a w32_CopyFile() is also present. I see both _boot_Win32 and
_w32_CopyFile listed in the output of dumpbin /all perl-static.exe, and
yet something is definitely amiss still.

If I install my static perl build (using the installbare target) and
then remove perl.exe and perl519.dll and rename perl-static.exe to
perl.exe I find that I can't build a simple XS module.

I took my own Win32::UTCFileTime as an example. The perl Makefile.PL
step works fine, but when I run nmake I get:

Undefined subroutine &Win32::CopyFile called at C:/perl/lib/File/Copy.pm
line 418.
NMAKE : fatal error U1077: 'C:\perl\bin\perl.exe' : return code '0x2'
Stop.

Ok, so that's actually a perl error about a perl function called
CopyFile(), and I shouldn't have gone off thinking that a C function
missing from the executable was the problem, but I'm still currently at
a loss to see why it isn't working. (It works fine if I use the normal
perl.exe and perl519.dll.)

Having said that, it seems to be something specific to the module Win32.
Randomly trying a few other XS things (Cwd, Sys::Hostname, Digest::MD5,
Encode) they appear to working fine.

What is special about Win32 that it doesn't work?

It's also still a puzzle to me why the perl-static.exe is only 2MB if it
contains everything necessary from perl519s.lib, which is 20MB.

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