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 13:30
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:
67B2BB40A61BE846B65EF4793B863D6CBB1C67@ukmail02.planit.group
Konovalov, Vadim (Vadim)** CTR ** wrote on 2013-06-06:
>> From: Nicholas Clark
>> 
>> So it's more a matter of porting the missing bits into the Win32
>> configuration system or the toolchain. Not doing everything from
>> scratch.
> 
> correct, and thanks for looking into this.
> 
> I'll see into the problem, right after June 10, if the problem will
> not be resolved at that time.
> (but if I succeed in my other plans on June 10, then possibilities
> will be to have permanent access to z/OS, so I am inspired and looking
> forward for the possibilities :):) :-)) )
> 

I've made some progress with this, but have run into what looks like a
more serious problem...

The attached patch does the following:

- Sets PERLSTATIC to 'static' when ALL_STATIC is defined (not just when
BUILD_STATIC is defined), otherwise there is nothing to instruct the
make program to even make the 'static' target (which is what makes
perl-static.exe and perl519s.lib/libperl519s.a). (How did this escape
unnoticed until now?!)

- Removes Extensions_static (the file listing the desired static
extensions) from the link command-line for perl-static.exe: I believe it
isn't necessary since we are linking against perl519s.lib/libperl519s.a
anyway, which already contains the same things. (This is the opposite of
what I tried before: I previously removed perl519s.lib/libperl519s.a
(and in fact removed the creation of them too, but apparently that
wasn't wise since MakeMaker needs it).)

- Reorders the lists of objects and libraries linked into perl.exe and
perl-static.exe to be consistent for both executables, in both makefiles
and (in makefile.mk) for both CCTYPEs. (Not strictly necessary, but it
just makes it easier to see the differences.)

- In the GCC case in makefile.mk, extracts the objects from each library
listed in Extensions_static and links those object files directly into
libperl519s.a, rather than linking in the libraries, which we found
earlier in this thread doesn't work.

- In Makefile only, removes Win32 and Encode from the list of exclusions
in the ALL_STATIC case (see below...).

I now have perl-static.exe building with VC++ and either
BUILD_STATIC=define or ALL_STATIC=define. It also builds with GCC with
BUILD_STATIC=define (just links in Win32CORE), but has a problem with
the Compress/Raw/BZip2 extension when trying ALL_STATIC=define (it
complains _BZ2_compressBlock is undefined, referenced from bzlib.o; I
don't know why GCC has a problem with that when VC++ doesn't).

That seemed like good progress and I was on the brink of committing it,
perhaps with an adjustment to the list of exclusions for GCC in the
ALL_STATIC case, but then I went and tested the damn thing, and now it's
all unravelling (or my brain is melting)...

In the VC++ build with ALL_STATIC I found that I couldn't build a simple
XS extension module: perl-static.exe (which I renamed to perl.exe in my
installation) has no dependencies on perl519.dll, but I found it loaded
Win32.dll which did, which seemed to defeat some of the point of this.
(I wanted to have a working setup with no perl519.dll at all.) The
reason is that Win32 was excluded from the list of static extensions, so
had been built dynamically in the usual manner. I therefore tried
removing it from the list of exclusions (and likewise Encode when I
found Encode.dll getting loaded too), and that seemed to work ok too --
it all built without error, so perhaps those exclusions are no longer
necessary (or maybe they never were? - perhaps whatever the problem was
related to Extensions_static and PERLSTATICLIB both being linked against
when only one is required?)?

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.

If I'm understanding this correctly then this will be a problem with all
of the extensions that we are trying to statically link in; this is not
specifically a problem with the Win32 extension.

And I don't know how to address this easily either. With the GCC linker
one can apparently use a -Wl,--whole-archive option to force the whole
library to get included, but the VC++ linker seems to have no such
option, e.g. see
http://social.msdn.microsoft.com/forums/en-US/vclanguage/thread/2aa2e1b7
-6677-4986-99cc-62f463c94ef3. (Does the UNIX/Linux build of a perl with
all extensions statically linked use that 'whole archive' option?)

I don't know where to go with this now.

One thing I haven't understood in this: what is the problem with dynamic
linking? Why does the Makefile claim "dynamic loading will not work with
this perl"? The perl-static.exe contains DynaLoader.o(bj) (it's the
DLL_OBJ, which is part of PERLDLL_OBJ, which is and always has been
included in perl-static.exe) and seemed to be loading Win32.dll and
Encode.dll just fine when I didn't want it to!...


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