[perl-win32-gui-hackers] Building Win32::GUI with Free MS VC++ 2003 toolkit [WasAny release soon?]

[Robert M. <rm...@po...>]

Glenn Linderman wrote:

> On approximately 6/20/2005 11:29 AM, came the following characters 
> from the keyboard of Robert May:
>
>> Glenn Linderman wrote:
>> [snipped conversation on the merits of MinGW, VC++ 6.0 and VC++ 7.0 
>> (aka .net)
>>
>>> I believe there are some library changes and such that cause VC++ 
>>> 6.0 and 7.0 and .net to require different versions of the 
>>> libraries... and since ActiveState is compiled with 6.0 that it is 
>>> best to compile XS extensions with 6.0 rather than the newer 
>>> compilers.  Not that it can't be made to work, I think, but that the 
>>> footprint of required libraries is larger.  PAR-built applications 
>>> could balloon in size, for example, if built with multiple 
>>> compilers.  At least, that I how I understand it.
>>
>> OK, there's an article discussing the VC 6/7 issues here:
>> http://www.perlmonks.org/?node=Free%20MSVC%20tools%20%2B%20Activestate%20to%20compile%20CPAN%20Modules 
>>
>> You need to be able to sort the wheat from the chaff, but I think the 
>> bottom line is that VC7 links against a new msvcr71.dll.  As I see it 
>> this will have the following effects:
>> (1) On a system with the new DLL it will load an extra DLL into 
>> memory.  I may then still not work.
>> (2) On a system without the new DLL it will fail to load.
>
OK, I had a bit of time to play this weekend.  The upshot is that I 
*THINK* I've successfully built both 5.6 and 5.8 PPM's using the free 
Visual C++ 2003 toolkit.  I *THINK* that I've convinced the compiler to 
link with the regular C runtime, and looking at the 4 builds I now have 
(MinGW 5.6, 5.8 and VC 5.6, 5.8) and comparing with the previous V1.0 
release, then using Process Explorer all runs appear to load exactly the 
same set of libraries, and exactly the same version numbers (except, of 
course, perl and Win32:GUI).  However, there are a couple of steps that 
I took in the build process that I still don't exactly understand, so 
I'm not going to pretend this is ready for the prime time yet.   In case 
anyone else is interested, here is what I've done so far:

(1) Download and install Visual C++ 2003 toolkit
http://msdn.microsoft.com/visualc/vctoolkit2003/
Download is ~32MB
This gives you the optimising compiler (cl.exe) and linker (link.exe), 
along with some basic header files and libraries.

(2) Download and install the Server 2003 platform SDK
http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en
Various downloads possible - I downloaded the ISO install and burned 
myself a disk - download size for full SDK ~400MB

All you actually need here is enough of the header files and library 
files to build and link with the common controls that Win32::GUI uses;  
I didn't have the time to try and work out which bits this was, so left 
the whole download running.  You also need the resource compiler (rc.exe)

(3) Get a msvcrt.lib file, to allow us to link with the dynamic 
multi-threading c run-time library (not included as part of the toolkit)
Apparently this is available as part of the .NET SDK download.   I 
couldn't face another huge download for one file, so followed these 
instructions to
build the .lib file from the .dll that we all have in our system32 
directory:
http://sapdb.2scale.net/moin.cgi/MS_20C_2b_2b_20Toolkit
See section on 'msvcrt.lib missing'
Put the generated msvcrt.lib into the lib directory of you toolkit install

(4) Prepare a command line environment with path, include and lib 
environment variables set up to point to the bin, include and lib 
folders of both the toolkit and the platform SDK.

(5) Build Win32::GUI
Perl Makefile.PL
nmake
nmake test

I had to make the following changes to get the build to work 
(specifically I ended up with 2 unresolved symbols at the link phase):

__fltused - fix resolution by adding the following code to the end of GUI.h.

#ifndef __FLTUSED__
#define __FLTUSED__
    extern "C" __declspec(selectany) int _fltused=1;
#endif

__CllMainCRTStartup@12 - fix resolution by adding -noentry to the linker 
command line (add to LDDLFLAGS in the Makefile).
I also changes a few command line options to eliminate warnings.  Here 
are the full set of changes I made to the Makefile:

LDDLFLAGS:
remove -debug (as I don't need debuggin information)
add -noentry  (fixes unresolved __DllMainCRTStartup@12 error)

CCFLAGS:
change -Gf to -GF (eliminates warning)
remove -Zi as I don't want debug information
remove -O1 (as it is duplicated in OPTIMIZE)

OPTIMIZE:
remove -MD -DNDEBUG (as these are duplicates from CCFLAGS)
remove -Zi as I don't want debug information

Hope this is of interest to some of you.  I am particularly interested 
in understanding more about the unresolved symobls, and whether my 
solutions are valid ones - any pointer gratefully received.

Regards,
Rob.