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
[EMAIL PROTECTED] - 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 [EMAIL PROTECTED] 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.
