MS Releases its C compiler for free.
Yves Orton
have the compiler and wont pay for it you may now do so from
http://www.microsoft.com/downloads/details.aspx?FamilyId=272BE09D-40BB-49FD-
9CB0-4BFA122FA91B&displaylang=en
This is a great day IMO for Win32 Perl users. "Theres no free compiler to
test against ActiveState Perl" is no longer a reason to release XS code that
doesnt work on Win32.
Ive had a look through it and the EULA seems to be perl friendly. Although
IANAL so i cant say for sure.
All I know is that I was able to build blead using the free compiler without
problem. Unfortunately though when I did so i did it on a machine with the
normal VDS 7 on it so its possible I ended up using resource available from
the non-free version during the build. I plan to restest it again on a clean
machine to see what issues are involved. We should ensure that going forward
we can build on the free compiler.
Incidentally one notable thing is the switch /Gf has been deprecated in the
new compiler apparently it should be /GF or removed outright. I havent the
foggiest what that means though.
Anyway, if this is old news sorry, but I think its good news so repeating it
cant be bad.
Yves
ps: Yah, no more XS hell for win32 folks using AS Perl without owning a
compiler!!!!
H.Merijn Brand
> For those who would like to build Perl with MS C but cant because they dont
> have the compiler and wont pay for it you may now do so from
>
> http://www.microsoft.com/downloads/details.aspx?FamilyId=272BE09D-40BB-49FD-9CB0-4BFA122FA91B&displaylang=en
>
> This is a great day IMO for Win32 Perl users. "Theres no free compiler to
> test against ActiveState Perl" is no longer a reason to release XS code that
> doesnt work on Win32.
OK, what to do next?
Microsoft (R) Program Maintenance Utility Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.
cp Zlib.pm blib\lib\Compress\Zlib.pm
AutoSplitting blib\lib\Compress\Zlib.pm (blib\lib\auto\Compress\Zlib)
C:\Util\Perl\bin\perl.exe C:\Util\Perl\lib\ExtUtils/xsubpp -typemap C:\Util\Perl\lib\ExtUtils\typemap -typemap typemap Zlib.xs > Zlib.xsc && C:\Util\Perl\bin\perl.exe -MExtUtils::Command -e mv Zlib.xsc Zlib.c
cl -c -I./zlib-src -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG -O1 -DVERSION=\"1.33\" -DXS_VERSION=\"1.33\" "-IC:\Util\Perl\lib\CORE" Zlib.c
Zlib.c
c1 : warning C4349: /Gf is deprecated and will not be supported in future versions of Visual C++; remove /Gf or use /GF instead
C:\Util\Perl\lib\CORE\perl.h(380) : fatal error C1083: Cannot open include file: 'sys/types.h': No such file or directory
NMAKE : fatal error U1077: 'C:\WINNT\system32\cmd.exe' : return code '0x2'
(Trying to build Compress-Zlib-1.33 on ActivePerl-809)
> Ive had a look through it and the EULA seems to be perl friendly. Although
> IANAL so i cant say for sure.
>
> All I know is that I was able to build blead using the free compiler without
> problem. Unfortunately though when I did so i did it on a machine with the
> normal VDS 7 on it so its possible I ended up using resource available from
> the non-free version during the build. I plan to restest it again on a clean
> machine to see what issues are involved. We should ensure that going forward
> we can build on the free compiler.
>
> Incidentally one notable thing is the switch /Gf has been deprecated in the
> new compiler apparently it should be /GF or removed outright. I havent the
> foggiest what that means though.
>
> Anyway, if this is old news sorry, but I think its good news so repeating it
> cant be bad.
>
> Yves
> ps: Yah, no more XS hell for win32 folks using AS Perl without owning a
> compiler!!!!
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.3, & 5.9.x, and 809 on HP-UX 10.20 & 11.00, 11i,
AIX 4.3, SuSE 9.0, and Win2k. http://www.cmve.net/~merijn/
http://archives.develooper.com/daily...@perl.org/ per...@perl.org
send smoke reports to: smokers...@perl.org, QA: http://qa.perl.org
Yves Orton
This _looks_ to me to be because you didnt run vcvars32.bat _before_ you ran
the nmake process.
vcvars32.bat sets up the enviornment with lib and include paths etc so it
has to happen first.
Actually the best thing to do is copy the values it sets into your SYSTEM
environment settings and then restart a fresh shell. This way the compiler
can run regardless of how it gets launched.
Dont forget to nuke any USER enviornment setting by the same name, or better
yet move them to be SYSTEM settings.
Then nmake and CL should be happy.
good luck.
:-)
H.Merijn Brand
> > c1 : warning C4349: /Gf is deprecated and will not be
> > supported in future versions of Visual C++; remove /Gf or use
> > /GF instead
> > C:\Util\Perl\lib\CORE\perl.h(380) : fatal error C1083: Cannot
> > open include file: 'sys/types.h': No such file or directory
> > NMAKE : fatal error U1077: 'C:\WINNT\system32\cmd.exe' :
> > return code '0x2'
>
> This _looks_ to me to be because you didnt run vcvars32.bat _before_ you ran
> the nmake process.
Of course I didn't How should I know ?
I added the bin path to my $PATH in bash
> vcvars32.bat sets up the enviornment with lib and include paths etc so it
> has to happen first.
>
> Actually the best thing to do is copy the values it sets into your SYSTEM
> environment settings and then restart a fresh shell. This way the compiler
> can run regardless of how it gets launched.
I'm running these from a perl script from bash under Cygwin from cygwin's
xterm with Reflection X11 client and HP-UX 11.00 as X11 server to complicate
the matter :)
> Dont forget to nuke any USER enviornment setting by the same name, or better
> yet move them to be SYSTEM settings.
I've included them in my .bashrc
> Then nmake and CL should be happy.
Noy yet complete:
Microsoft (R) Program Maintenance Utility Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.
cp Zlib.pm blib\lib\Compress\Zlib.pm
AutoSplitting blib\lib\Compress\Zlib.pm (blib\lib\auto\Compress\Zlib)
C:\Util\Perl\bin\perl.exe C:\Util\Perl\lib\ExtUtils/xsubpp -typemap C:\Util\Perl\lib\ExtUtils\typemap -typemap typemap Zlib.xs > Zlib.xsc && C:\Util\Perl\bin\perl.exe -MExtUtils::Command -e mv Zlib.xsc Zlib.c
cl -c -I./zlib-src -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG -O1 -DVERSION=\"1.33\" -DXS_VERSION=\"1.33\" "-IC:\Util\Perl\lib\CORE" Zlib.c
Zlib.c
c1 : warning C4349: /Gf is deprecated and will not be supported in future versions of Visual C++; remove /Gf or use /GF instead
c:\Util\Perl\lib\CORE\win32.h(61) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory
NMAKE : fatal error U1077: 'C:\WINNT\system32\cmd.exe' : return code '0x2'
Stop.
> good luck.
>
> :-)
Yves Orton
> On Mon 19 Apr 2004 15:12, "Orton, Yves" <yves....@de.mci.com> wrote:
> > > c1 : warning C4349: /Gf is deprecated and will not be
> > > supported in future versions of Visual C++; remove /Gf or use
> > > /GF instead
> > > C:\Util\Perl\lib\CORE\perl.h(380) : fatal error C1083: Cannot
> > > open include file: 'sys/types.h': No such file or directory
> > > NMAKE : fatal error U1077: 'C:\WINNT\system32\cmd.exe' :
> > > return code '0x2'
> >
> > This _looks_ to me to be because you didnt run vcvars32.bat
> _before_ you ran
> > the nmake process.
>
> Of course I didn't How should I know ?
> I added the bin path to my $PATH in bash
You probably dont want to build under bash. I cant say for sure but I dont
think you want to do that.
Use the /win32 Makefile with nmake.exe under cmd.exe
>
> > vcvars32.bat sets up the enviornment with lib and include
> paths etc so it
> > has to happen first.
> >
> > Actually the best thing to do is copy the values it sets
> into your SYSTEM
> > environment settings and then restart a fresh shell. This
> way the compiler
> > can run regardless of how it gets launched.
>
> I'm running these from a perl script from bash under Cygwin
> from cygwin's
> xterm with Reflection X11 client and HP-UX 11.00 as X11
> server to complicate
> the matter :)
Oh god.
>
> > Dont forget to nuke any USER enviornment setting by the
> same name, or better
> > yet move them to be SYSTEM settings.
>
> I've included them in my .bashrc
Hmm. I have no idea how thatll work out. :-)
Note that below the makefile is actually calling out to CMD.EXE not into
bash.
RE the missing windows.h file: it is definately not included in the
compiler.
We need to identify what is being used from this file and figure out if or
where it is located in the free compiler.
Its also possible that in order to build people need to get the full SDK and
not just the compiler toolkit.
Ill look into this more later.
Nick Ing-Simmons
>On Mon 19 Apr 2004 12:35, "Orton, Yves" <yves....@de.mci.com> wrote:
>> For those who would like to build Perl with MS C but cant because they dont
>> have the compiler and wont pay for it you may now do so from
>>
>> http://www.microsoft.com/downloads/details.aspx?FamilyId=272BE09D-40BB-49FD-9CB0-4BFA122FA91B&displaylang=en
>>
>> This is a great day IMO for Win32 Perl users. "Theres no free compiler to
>> test against ActiveState Perl" is no longer a reason to release XS code that
>> doesnt work on Win32.
>
>OK, what to do next?
>
>Microsoft (R) Program Maintenance Utility Version 1.50
>Copyright (c) Microsoft Corp 1988-94. All rights reserved.
>
>cp Zlib.pm blib\lib\Compress\Zlib.pm
>AutoSplitting blib\lib\Compress\Zlib.pm (blib\lib\auto\Compress\Zlib)
> C:\Util\Perl\bin\perl.exe C:\Util\Perl\lib\ExtUtils/xsubpp -typemap C:\Util\Perl\lib\ExtUtils\typemap -typemap typemap Zlib.xs > Zlib.xsc && C:\Util\Perl\bin\perl.exe -MExtUtils::Command -e mv Zlib.xsc Zlib.c
> cl -c -I./zlib-src -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG -O1 -DVERSION=\"1.33\" -DXS_VERSION=\"1.33\" "-IC:\Util\Perl\lib\CORE" Zlib.c
>Zlib.c
>c1 : warning C4349: /Gf is deprecated and will not be supported in future versions of Visual C++; remove /Gf or use /GF instead
>C:\Util\Perl\lib\CORE\perl.h(380) : fatal error C1083: Cannot open include file: 'sys/types.h': No such file or directory
>NMAKE : fatal error U1077: 'C:\WINNT\system32\cmd.exe' : return code '0x2'
Normal VC++ has VCVARS.BAT or can put %INCLUDE% in the registry to
indicate where standard includes are hidden.
Horsley Tom
> ActivePerl in the past, and I don't see us changing that anytime soon.
The main reason I stuck with 6.0 at home was I didn't want
to drag all the .NET crap onto my system (so far I've been
able to avoid both .NET and cygwin :-).
Jan Dubois
<yves....@de.mci.com> wrote:
>For those who would like to build Perl with MS C but cant because they dont
>have the compiler and wont pay for it you may now do so from
>
>http://www.microsoft.com/downloads/details.aspx?FamilyId=272BE09D-40BB-49FD-
>9CB0-4BFA122FA91B&displaylang=en
>
>This is a great day IMO for Win32 Perl users. "Theres no free compiler to
>test against ActiveState Perl" is no longer a reason to release XS code that
>doesnt work on Win32.
You could get VC++ for free for a couple of years already; it is part of
the .NET Framework redistributable.
The new (and indeed very cool) thing is that now the code optimizer is
included in the free version too.
There is one thing I don't like about VC++ 7.0 and later: it no longer
uses the C runtime library that is part of the OS: msvcrt.dll. Instead
it now bundles a versioned library with each compiler release. We have
already seen msvcr70.dll and msvcr71.dll. So if you compile modules
with different compiler versions, you end up loading multiple runtimes
into your process. And if you want to wrap your Perl program with PAR,
PerlApp or Perl2Exe, then you'll have to ship all these runtime
libraries as well whereas you know that you already have msvcrt.dll on
each potential deployment system.
This is one of the major reasons we decided to stick with VC++ 6.0 for
ActivePerl in the past, and I don't see us changing that anytime soon.
This doesn't mean that you can't compile modules for ActivePerl with
VC++ 7.x; you will just end up with multiple runtime dependencies, just
as if you compile Perl 7.0 and the module with 7.1.
Cheers,
-Jan
Yves Orton
>
> Microsoft (R) Program Maintenance Utility Version 1.50
> Copyright (c) Microsoft Corp 1988-94. All rights reserved.
>
> cp Zlib.pm blib\lib\Compress\Zlib.pm
> AutoSplitting blib\lib\Compress\Zlib.pm (blib\lib\auto\Compress\Zlib)
> C:\Util\Perl\bin\perl.exe
> C:\Util\Perl\lib\ExtUtils/xsubpp -typemap
> C:\Util\Perl\lib\ExtUtils\typemap -typemap typemap Zlib.xs >
> Zlib.xsc && C:\Util\Perl\bin\perl.exe -MExtUtils::Command -e
> mv Zlib.xsc Zlib.c
> cl -c -I./zlib-src -nologo -Gf -W3 -MD -Zi -DNDEBUG
> -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT
> -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS
> -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG -O1
> -DVERSION=\"1.33\" -DXS_VERSION=\"1.33\"
> "-IC:\Util\Perl\lib\CORE" Zlib.c
> Zlib.c
> c1 : warning C4349: /Gf is deprecated and will not be
> supported in future versions of Visual C++; remove /Gf or use
> /GF instead
> open include file: 'windows.h': No such file or directory
> NMAKE : fatal error U1077: 'C:\WINNT\system32\cmd.exe' :
> return code '0x2'
Hi folks, i can report the missing header files are in the MS Windows
Platform SDK, which can be obtained from MS as well.
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
Unfortunately it looks like you must be using IE to download it as it uses
an ActiveX component to manage the install.
Once you installed the SDK you need to update your include and lib paths,
and it _should_ build fine.
More to come later.
Yves
Jan Dubois
wrote:
>According to Jan Dubois:
>> So if you compile modules with different compiler versions, you end
>> up loading multiple runtimes into your process.
>
>Completely aside from the question of whether that's desirable, does
>it actually work? Multiple libcs on Linux means instant SEGV, and
>that's if you're lucky.
It typically does work because Perl doesn't use much of the runtime
library, and makes sure that all calls from XS modules go through the
Perl abstraction layer.
In some sense you already have 2 different runtime libraries if you use
PERL_MALLOC. You just have to make sure that you don't pass runtime
objects (FILE* handles, memory blocks etc) to the "other" runtime
library.
Here is a message from the Microsoft CRT dev lead about this topic:
http://groups.google.com/groups?selm=eFQ%23lcp2BHA.2112%40tkmsftngp02
Cheers,
-Jan
Chip Salzenberg
> So if you compile modules with different compiler versions, you end
> up loading multiple runtimes into your process.
Completely aside from the question of whether that's desirable, does
it actually work? Multiple libcs on Linux means instant SEGV, and
that's if you're lucky.
--
Chip Salzenberg - a.k.a. - <ch...@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Yves Orton
> > So if you compile modules with different compiler versions, you end
> > up loading multiple runtimes into your process.
>
> Completely aside from the question of whether that's desirable, does
> it actually work? Multiple libcs on Linux means instant SEGV, and
> that's if you're lucky.
Yes it works. I have been building extensions under VC 7 for over a year now
that work fine with AS builds of perl.
Since i always had the dotnet stuff on the machines I was using I never even
realized it was using different CRT's.
So really the only place this is important is with regard to PPM's.
But IMO this announcment is long term pretty close to the end of needing
PPM's for Win32 users.
Also we should update the WIN32 docs to include links to the required
resources to get it built.
yves
Mark Mielke
> According to Jan Dubois:
> > So if you compile modules with different compiler versions, you end
> > up loading multiple runtimes into your process.
> Completely aside from the question of whether that's desirable, does
> it actually work? Multiple libcs on Linux means instant SEGV, and
> that's if you're lucky.
This isn't true. For the Windows scenario, note that the .dll's have
different names. For the UNIX case, shared libraries can usually be
versioned quite easily. The problem is when the executables don't
select the proper version, and the version is incompatible...
mark
--
ma...@mielke.cc/ma...@ncf.ca/ma...@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
Yves Orton
> is part of
> the .NET Framework redistributable.
Ah, I wish had known that.
> The new (and indeed very cool) thing is that now the code optimizer is
> included in the free version too.
Thanks for the clarification.
> There is one thing I don't like about VC++ 7.0 and later: it no longer
> uses the C runtime library that is part of the OS:
> msvcrt.dll. Instead
> it now bundles a versioned library with each compiler
> release. We have
> already seen msvcr70.dll and msvcr71.dll. So if you compile modules
> with different compiler versions, you end up loading multiple runtimes
> into your process. And if you want to wrap your Perl program
> with PAR,
> PerlApp or Perl2Exe, then you'll have to ship all these runtime
> libraries as well whereas you know that you already have msvcrt.dll on
> each potential deployment system.
Yes this is an issue worth keeping in mind.
> This is one of the major reasons we decided to stick with VC++ 6.0 for
> ActivePerl in the past, and I don't see us changing that anytime soon.
> This doesn't mean that you can't compile modules for ActivePerl with
> VC++ 7.x; you will just end up with multiple runtime
> dependencies, just
> as if you compile Perl 7.0 and the module with 7.1.
This wont really be a problem then. Assuming people are building extensions
at home/work then they will have the version provided by the compiler and
the one that AS perl uses.
Thanks for explaining the rationale by the way, i had wondered why you hadnt
made the change yet.
Yves
Chip Salzenberg
> On Mon, Apr 19, 2004 at 11:15:49AM -0400, Chip Salzenberg wrote:
> > Completely aside from the question of whether that's desirable, does
> > it actually work? Multiple libcs on Linux means instant SEGV, and
> > that's if you're lucky.
>
> This isn't true.
Of course it is. Consider the result of this hypothetical problem:
prog -> libfoo -> glibc6.2
prog -> libperl -> glibc6.3
Oops. Proper version control will avoid this, but since version
control is not always proper, it does happen. It's more likely to
occur with libstdc++ in my experience, but I've seen it with libc as
well. (You just have to pick a particularly benighted "libfoo".)
Horsley Tom
> > > that's if you're lucky.
> >
> > This isn't true.
>
> Of course it is. Consider the result of this hypothetical problem:
>
> prog -> libfoo -> glibc6.2
> prog -> libperl -> glibc6.3
>
> Oops. Proper version control will avoid this, but since version
> control is not always proper, it does happen. It's more likely to
> occur with libstdc++ in my experience, but I've seen it with libc as
> well. (You just have to pick a particularly benighted "libfoo".)
Worse yet, the traditional technique for solving the dllhell problem
(i.e. static linking) doesn't work either because (on redhat at least)
there are now static libraries that invoke dlopen in their innards,
loading libraries which reference libc versions you didn't static
link with, dragging in multiple versions of malloc, etc. Program
go boom :-(.
The Persico Family
> Hi folks, i can report the missing header files are in the MS
> Windows
> Platform SDK, which can be obtained from MS as well.
>
> http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
>
> Unfortunately it looks like you must be using IE to download it as
> it uses
> an ActiveX component to manage the install.
>
> Once you installed the SDK you need to update your include and lib
> paths,
> and it _should_ build fine.
Does the SDK Core include nmake.exe or do we have to obtain that separately?
>
> More to come later.
>
> Yves
--
Matthew O. Persico
The Persico Family
> Hi folks, i can report the missing header files are in the MS
> Windows
> Platform SDK, which can be obtained from MS as well.
>
> http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
>
> Unfortunately it looks like you must be using IE to download it as
> it uses
> an ActiveX component to manage the install.
>
> Once you installed the SDK you need to update your include and lib
> paths,
> and it _should_ build fine.
Download size: 179.4 MB
Install size required: 504.5 MB
Yikes!
Core SDK (Windows Server 2003) 201.7 MB / Download Time: 8 hr 11 min / Updated: February 2003 (Build 5.2.3790.0) Read This First
Build environment (31 MB)
Build environment (Intel 64-bit) (67.6 MB)
Documentation (release and prerelease) (91.6 MB)
Sample and source code (10.6 MB)
YIKES!
--------------------------------------------------------------------------------
Update Dependencies
The SDKs you have selected require the following components, which will also be installed.
Windows Installer Control
40 KB / Download Time: < 1 min / Updated: Tuesday, April 01, 2003
Performs the installation of Windows Installer files on your computer. (Build 5.2.3790.0)
Installation Control (40 KB)
Common Setup Files
11.7 MB / Download Time: 1 hr 18 min / Updated: February 2003
(Build 5.2.3790.0)
Common Setup Files (11.7 MB)
AAAGGHHHH!!! Bill is messing with my machine again!
I now understand why people stick with 6.0. I, for my part, am ordering the CD (USD8.95) so I can install just the pieces I need, I'm afraid of this Active X control stuff and how do I rebuild in case of catastrophe? Suck it down from the net again?
Just my USD 0.02
--
Matthew O. Persico
Yves Orton
> that separately?
No its not included I dont think.
But MS has it somewhere, you can find a link in the perlwin32 pod iirc
Yves
H.Merijn Brand
I got it somewhere else. Can't remember where, but I bet Google will tell me
http://download.microsoft.com/download/vc15/Patch/1.52/W95/EN-US/Nmake15.exe
is the same version I use
> > More to come later.
>
> --
> Matthew O. Persico
Gisle Aas
> But MS has it somewhere, you can find a link in the perlwin32 pod iirc
The nmake links are found here:
[gisle@caliper perl-current]$ search nmake | grep microsoft
README.win32: ftp://ftp.microsoft.com/Softlib/MSLFILES/nmake15.exe
pod/perlmodinstall.pod: ftp://ftp.microsoft.com/Softlib/MSLFILES/nmake15.exe
lib/ExtUtils/README: ftp://ftp.microsoft.com/Softlib/MSLFILES/nmake15.exe nmake
--Gisle
Paul Marquess
> On Wed 21 Apr 2004 04:33, The Persico Family <persico...@verizon.net>
> wrote:
> > On Mon, 19 Apr 2004 16:09:46 +0100, Orton, Yves typed:
> >
> > > Hi folks, i can report the missing header files are in the MS Windows
> > > Platform SDK, which can be obtained from MS as well.
> > >
> > > http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
> > >
> > > Unfortunately it looks like you must be using IE to download it as
> > > it uses an ActiveX component to manage the install.
> > >
> > > Once you installed the SDK you need to update your include and lib
> > > paths, and it _should_ build fine.
The Platform SDK says it needs 500Meg of disk space when installed. Is the
only thing needed from it the include files? I'd prefer not to waste disk
space if possible.
Paul
H.Merijn Brand
Same reason here why I waited for more comments.
Marcus Holland-Moritz
> On Wed 21 Apr 2004 12:23, "Paul Marquess" <Paul.M...@btinternet.com> wrote:
> > >
> > > On Wed 21 Apr 2004 04:33, The Persico Family <persico...@verizon.net>
> > > wrote:
> > > > On Mon, 19 Apr 2004 16:09:46 +0100, Orton, Yves typed:
> > > >
> > > > > Hi folks, i can report the missing header files are in the MS Windows
> > > > > Platform SDK, which can be obtained from MS as well.
> > > > >
> > > > > http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
> > > > >
> > > > > Unfortunately it looks like you must be using IE to download it as
> > > > > it uses an ActiveX component to manage the install.
> > > > >
> > > > > Once you installed the SDK you need to update your include and lib
> > > > > paths, and it _should_ build fine.
> >
> > The Platform SDK says it needs 500Meg of disk space when installed. Is the
> > only thing needed from it the include files? I'd prefer not to waste disk
> > space if possible.
>
> Same reason here why I waited for more comments.
I tried to install all of this SDK/.NET/... crap a while ago,
along with the compiler that was freely available back then.
After I've installed _absolutely_everything_, which was way
over 1 Gig, I still couldn't get Perl to compile because of
missing libs. Unfortunately I don't remember which ones.
After spending _hours_ (not including download time) I gave up.
So that's my experience with the M$ cripple^Wfreeware.
Marcus
--
BOFH Excuse #175:
OS swapped to disk
H.Merijn Brand
> On 2004-04-21, at 12:47:30 +0200, H.Merijn Brand wrote:
>
> > On Wed 21 Apr 2004 12:23, "Paul Marquess" <Paul.M...@btinternet.com> wrote:
> > > >
> > > > On Wed 21 Apr 2004 04:33, The Persico Family <persico...@verizon.net>
> > > > wrote:
> > > > > On Mon, 19 Apr 2004 16:09:46 +0100, Orton, Yves typed:
> > > > >
> > > > > > Hi folks, i can report the missing header files are in the MS Windows
> > > > > > Platform SDK, which can be obtained from MS as well.
> > > > > >
> > > > > > http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
> > > > > >
> > > > > > Unfortunately it looks like you must be using IE to download it as
> > > > > > it uses an ActiveX component to manage the install.
> > > > > >
> > > > > > Once you installed the SDK you need to update your include and lib
> > > > > > paths, and it _should_ build fine.
> > >
> > > The Platform SDK says it needs 500Meg of disk space when installed. Is the
> > > only thing needed from it the include files? I'd prefer not to waste disk
> > > space if possible.
> >
> > Same reason here why I waited for more comments.
>
> I tried to install all of this SDK/.NET/... crap a while ago,
> along with the compiler that was freely available back then.
So, just for testing sake, Yves, make use the
include folders with the missing header files
available as URL/tgz please
> After I've installed _absolutely_everything_, which was way
> over 1 Gig, I still couldn't get Perl to compile because of
> missing libs. Unfortunately I don't remember which ones.
>
> After spending _hours_ (not including download time) I gave up.
>
> So that's my experience with the M$ cripple^Wfreeware.
>
> Marcus
>
> --
> BOFH Excuse #175:
>
> OS swapped to disk
--
Beau E. Cox
Hi -
I had no problems compiling perl under the previous MS free version of
the VC++ 7.0 compiler (or Apache, mod_perl, etc.). My mini-HOWTO -
now out-of-date - shows what I did:
http://beaucox.com/mini-HOWTOs/win32-setup-mini-HOWTO.htm#c/c++_026
I haven't tried the latest one yet.
Aloha => Beau;
Matthew O. Persico
> On Wed 21 Apr 2004 04:33, The Persico Family wrote:
>> On Mon, 19 Apr 2004 16:09:46 +0100, Orton, Yves typed:
>>
>>> Hi folks, i can report the missing header files are in the MS
>>> Windows
>>> Platform SDK, which can be obtained from MS as well.
>>>
>>> http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
>>>
>>> Unfortunately it looks like you must be using IE to download it
>>> as
>>> it uses an ActiveX component to manage the install.
>>>
>>> Once you installed the SDK you need to update your include and
>>> lib
>>> paths, and it _should_ build fine.
>>
>> Does the SDK Core include nmake.exe or do we have to obtain that
>> separately?
>
> I got it somewhere else. Can't remember where, but I bet Google
> will tell me
>
</rant>
--
Matthew
Matthew O. Persico
Free, yeah, you get what you pay for.
Back to VC++6.0.
> I haven't tried the latest one yet.
>
> Aloha => Beau;
--
Matthew O. Persico
Beau E. Cox
> On Wed, 21 Apr 2004 06:47:20 -1000, Beau E. Cox typed:
>
> 500frigginMB and I STILL need to pull files from all over the internet???
>
> Free, yeah, you get what you pay for.
>
> Back to VC++6.0.
>
> > I haven't tried the latest one yet.
> >
> > Aloha => Beau;
>
Matthew -
Relax ;)
Aloha => Beau;
Matthew O. Persico
I'm perfectly relaxed, now that I've gone back to VC6.0++. Besides, there's only so much relaxing you're going to do in New York anyway.
>
> Aloha => Beau;
Yo=>Matt :-)