=head1 SYNOPSIS
These are instructions for building Perl under Windows NT (versions
-3.51 or 4.0). Currently, this port is reported to build
-under Windows95 using the 4DOS shell--the default shell that infests
-Windows95 will not work (see below). Note this caveat is only about
-B<building> perl. Once built, you should be able to B<use> it on
-either Win32 platform (modulo the problems arising from the inferior
-command shell).
+3.51 or 4.0). Currently, this port is reported to build under
+Windows95 using the 4DOS shell--the default shell that infests
+Windows95 may not work fully (but see below). Note that this caveat
+is only about B<building> perl. Once built, you should be able to
+B<use> it on either Win32 platform (modulo the problems arising from
+the inferior command shell).
=head1 DESCRIPTION
"Configure".
You may also want to look at two other options for building
-a perl that will work on Windows NT: the README.cygwin32 and
+a perl that will work on Windows NT: the README.cygwin and
README.os2 files, which each give a different set of rules to build
a Perl that will work on Win32 platforms. Those two methods will
probably enable you to build a more Unix-compatible perl, but you
Borland C++ version 5.02 or later
Microsoft Visual C++ version 4.2 or later
- Mingw32 with EGCS version 1.0.2
- Mingw32 with GCC version 2.8.1
+ Mingw32 with GCC version 2.95.2 or better
-The last two of these are high quality freeware compilers. Support
-for them is still experimental.
+The last of these is a high quality freeware compiler. Support
+for it is still experimental. (Older versions of GCC are known
+not to work.)
This port currently supports MakeMaker (the set of modules that
is used to build extensions to perl). Therefore, you should be
Use the default "cmd" shell that comes with NT. Some versions of the
popular 4DOS/NT shell have incompatibilities that may cause you trouble.
If the build fails under that shell, try building again with the cmd
-shell. The Makefile also has known incompatibilites with the "command.com"
-shell that comes with Windows95, so building under Windows95 should
-be considered "unsupported". However, there have been reports of successful
-build attempts using 4DOS/NT version 3.00 under Windows95, using dmake, but
-your mileage may vary.
+shell. The nmake Makefile also has known incompatibilites with the
+"command.com" shell that comes with Windows95.
-The surest way to build it is on WindowsNT, using the cmd shell.
+However, there have been reports of successful build attempts using
+4DOS/NT version 6.01 under Windows95, using dmake, but your mileage
+may vary. There is also some basic support for building using dmake
+under command.com. Nevertheless, if building under command.com
+doesn't work, try 4DOS/NT.
+
+The surest way to build it is on Windows NT, using the cmd shell.
+
+Make sure the path to the build directory does not contain spaces. The
+build usually works in this circumstance, but some tests will fail.
=item Borland C++
A port of dmake for win32 platforms is available from:
- http://www-personal.umich.edu/~gsar/dmake-4.1-win32.zip
+ http://cpan.perl.org/authors/id/GSAR/dmake-4.1pl1-win32.zip
+
+(This is a fixed version of original dmake sources obtained from
+http://www.wticorp.com/dmake/. As of version 4.1PL1, the original
+sources did not build as shipped, and had various other problems.
+A patch is included in the above fixed version.)
Fetch and install dmake somewhere on your path (follow the instructions
in the README.NOW file).
=item Microsoft Visual C++
-The NMAKE that comes with Visual C++ will suffice for building.
+The nmake that comes with Visual C++ will suffice for building.
You will need to run the VCVARS32.BAT file usually found somewhere
like C:\MSDEV4.2\BIN. This will set your build environment.
latter step is only essential if you want to use dmake as your default
make for building extensions using MakeMaker.
-=item Mingw32 with EGCS or GCC
+=item Mingw32 with GCC
-ECGS-1.0.2 binaries can be downloaded from:
+GCC-2.95.2 binaries can be downloaded from:
ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/
-GCC-2.8.1 binaries are available from:
-
- http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32/
+The GCC-2.95.2 bundle comes with Mingw32 libraries and headers.
-You only need either one of those, not both. Both bundles come with
-Mingw32 libraries and headers. While both of them work to build perl,
-the EGCS binaries are currently favored by the maintainers, since they
-come with more up-to-date Mingw32 libraries.
+Make sure you install the binaries that work with MSVCRT.DLL as indicated
+in the README for the GCC bundle. You may need to set up a few environment
+variables (usually run from a batch file).
-Make sure you install the binaries as indicated in the web sites
-above. You will need to set up a few environment variables (usually
-run from a batch file).
+You also need dmake. See L</"Borland C++"> above on how to get it.
=back
Make sure you are in the "win32" subdirectory under the perl toplevel.
This directory contains a "Makefile" that will work with
-versions of NMAKE that come with Visual C++, and a dmake "makefile.mk"
+versions of nmake that come with Visual C++, and a dmake "makefile.mk"
that will work for all supported compilers. The defaults in the dmake
makefile are setup to build using the Borland compiler.
ActiveState Tool Corp.) PERL_OBJECT uses C++, and the binaries are
therefore incompatible with the regular C build. However, the
PERL_OBJECT build does provide something called the C-API, for linking
-it with extensions that won't compile under PERL_OBJECT. PERL_OBJECT
-cannot be enabled when using GCC or EGCS, yet.
+it with extensions that won't compile under PERL_OBJECT. Using the C_API
+is typically requested through:
+
+ perl Makefile.PL CAPI=TRUE
+
+PERL_OBJECT requires VC++ 5.0 (Service Pack 3 recommended) or later. It
+is not yet supported under GCC. WARNING: Binaries built with
+PERL_OBJECT enabled are B<not> compatible with binaries built without.
+Perl installs PERL_OBJECT binaries under a distinct architecture name,
+so they B<can> coexist, though.
Beginning with version 5.005, there is experimental support for building
a perl interpreter that is capable of native threading. Binaries built
with thread support enabled are also incompatible with the vanilla C
-build.
+build. WARNING: Binaries built with threads enabled are B<not> compatible
+with binaries built without. Perl installs threads enabled binaries under
+a distinct architecture name, so they B<can> coexist, though.
At the present time, you cannot enable both threading and PERL_OBJECT.
You can get only one of them in a Perl interpreter.
enable the appropriate option in the makefile. des_fcrypt() is not
bundled with the distribution due to US Government restrictions
on the export of cryptographic software. Nevertheless, this routine
-is part of the "libdes" library (written by Ed Young) which is widely
+is part of the "libdes" library (written by Eric Young) which is widely
available worldwide, usually along with SSLeay (for example:
"ftp://fractal.mta.ca/pub/crypto/SSLeay/DES/"). Set CRYPT_SRC to the
name of the file that implements des_fcrypt(). Alternatively, if
you have built a library that contains des_fcrypt(), you can set
-CRYPT_LIB to point to the library name.
+CRYPT_LIB to point to the library name. The location above contains
+many versions of the "libdes" library, all with slightly different
+implementations of des_fcrypt(). Older versions have a single,
+self-contained file (fcrypt.c) that implements crypt(), so they may be
+easier to use. A patch against the fcrypt.c found in libdes-3.06 is
+in des_fcrypt.patch.
Perl will also build without des_fcrypt(), but the crypt() builtin will
fail at run time.
You will also have to make sure CCHOME points to wherever you installed
your compiler.
+The default value for CCHOME in the makefiles for Visual C++
+may not be correct for some versions. Make sure the default exists
+and is valid.
+
Other options are explained in the makefiles. Be sure to read the
instructions carefully.
Type "dmake" (or "nmake" if you are using that make).
This should build everything. Specifically, it will create perl.exe,
-perl.dll (or perlcore.dll), and perlglob.exe at the perl toplevel, and
+perl.dll (or perl56.dll), and perlglob.exe at the perl toplevel, and
various other extension dll's under the lib\auto directory. If the build
fails for any reason, make sure you have done the previous steps correctly.
less copiously, depending on how picky your compiler gets). The
maintainers are aware of these warnings, thankyouverymuch. :)
-When building using Visual C++, a perl95.exe will also get built. This
-executable is only needed on Windows95, and should be used instead of
-perl.exe, and then only if you want sockets to work properly on Windows95.
-This is necessitated by a bug in the Microsoft C Runtime that cannot be
-worked around in the "normal" perl.exe. perl95.exe gets built with its
-own private copy of the C Runtime that is not accessible to extensions
-(which see the DLL version of the CRT). Be aware, therefore, that this
-perl95.exe will have esoteric problems with extensions like perl/Tk that
-themselves use the C Runtime heavily, or want to free() pointers
-malloc()-ed by perl.
-
-You can avoid the perl95.exe problems completely if you use Borland
-C++ for building perl (perl95.exe is not needed and will not be built
-in that case).
-
=back
=head2 Testing
the testsuite (many tests will be skipped, and but no test should fail).
If some tests do fail, it may be because you are using a different command
-shell than the native "cmd.exe".
+shell than the native "cmd.exe", or because you are building from a path
+that contains spaces. So don't do that.
+
+If you are running the tests from a emacs shell window, you may see
+failures in op/stat.t. Run "dmake test-notty" in that case.
-If you used the Borland compiler, you may see a failure in op/taint.t
+If you're using the Borland compiler, you may see a failure in op/taint.t
arising from the inability to find the Borland Runtime DLLs on the system
default path. You will need to copy the DLLs reported by the messages
from where Borland chose to install it, into the Windows system directory
(usually somewhere like C:\WINNT\SYSTEM32), and rerun the test.
-The Visual C runtime apparently has a bug that causes posix.t to fail
-one it test#2. This usually happens only if you extracted the files in
-text mode.
-
Please report any other failures as described under L<BUGS AND CAVEATS>.
=head2 Installation
C<$INST_TOP\$VERSION\bin>, and C<$INST_TOP\$VERSION\bin\$ARCHNAME>.
For example:
- set PATH c:\perl\5.005\bin;c:\perl\5.005\bin\MSWin32-x6;%PATH%
+ set PATH c:\perl\5.005\bin;c:\perl\5.005\bin\MSWin32-x86;%PATH%
=head2 Usage Hints
You can also control the shell that perl uses to run system() and
backtick commands via PERL5SHELL. See L<perlrun>.
-Currently, Perl does not depend on the registry, but can look up
-values if you choose to put them there. [XXX add registry locations
-that perl looks at here.]
+Perl does not depend on the registry, but it can look up certain default
+values if you choose to put them there. Perl attempts to read entries from
+C<HKEY_CURRENT_USER\Software\Perl> and C<HKEY_LOCAL_MACHINE\Software\Perl>.
+Entries in the former override entries in the latter. One or more of the
+following entries (of type REG_SZ or REG_EXPAND_SZ) may be set:
+
+ lib-$] version-specific path to add to @INC
+ lib path to add to @INC
+ sitelib-$] version-specific path to add to @INC
+ sitelib path to add to @INC
+ PERL* fallback for all %ENV lookups that begin with "PERL"
+
+Note the C<$]> in the above is not literal. Substitute whatever version
+of perl you want to honor that entry, e.g. C<5.00502>. Paths must be
+separated with semicolons, as usual on win32.
=item File Globbing
$MAKE test
$MAKE install
-where $MAKE stands for NMAKE or DMAKE. Some extensions may not
-provide a testsuite (so "$MAKE test" may not do anything, or fail),
-but most serious ones do.
+where $MAKE is whatever 'make' program you have configured perl to
+use. Use "perl -V:make" to find out what this is. Some extensions
+may not provide a testsuite (so "$MAKE test" may not do anything, or
+fail), but most serious ones do.
+
+It is important that you use a supported 'make' program, and
+ensure Config.pm knows about it. If you don't have nmake, you can
+either get dmake from the location mentioned earlier, or get an
+old version of nmake reportedly available from:
+
+ ftp://ftp.microsoft.com/Softlib/MSLFILES/nmake15.exe
+
+Another option is to use the make written in Perl, available from
+CPAN:
+
+ http://www.perl.com/CPAN/authors/id/NI-S/Make-0.03.tar.gz
+
+Note that MakeMaker actually emits makefiles with different syntax
+depending on what 'make' it thinks you are using. Therefore, it is
+important that one of the following values appears in Config.pm:
+
+ make='nmake' # MakeMaker emits nmake syntax
+ make='dmake' # MakeMaker emits dmake syntax
+ any other value # MakeMaker emits generic make syntax
+ (e.g GNU make, or Perl make)
+
+If the value doesn't match the 'make' program you want to use,
+edit Config.pm to fix it.
If a module implements XSUBs, you will need one of the supported
C compilers. You must make sure you have set up the environment for
that with full details of how the build failed using the perlbug
utility.
+=item Command-line Wildcard Expansion
+
+The default command shells on DOS descendant operating systems (such
+as they are) usually do not expand wildcard arguments supplied to
+programs. They consider it the application's job to handle that.
+This is commonly achieved by linking the application (in our case,
+perl) with startup code that the C runtime libraries usually provide.
+However, doing that results in incompatible perl versions (since the
+behavior of the argv expansion code differs depending on the
+compiler, and it is even buggy on some compilers). Besides, it may
+be a source of frustration if you use such a perl binary with an
+alternate shell that *does* expand wildcards.
+
+Instead, the following solution works rather well. The nice things
+about it: 1) you can start using it right away 2) it is more powerful,
+because it will do the right thing with a pattern like */*/*.c
+3) you can decide whether you do/don't want to use it 4) you can
+extend the method to add any customizations (or even entirely
+different kinds of wildcard expansion).
+
+ C:\> copy con c:\perl\lib\Wild.pm
+ # Wild.pm - emulate shell @ARGV expansion on shells that don't
+ use File::DosGlob;
+ @ARGV = map {
+ my @g = File::DosGlob::glob($_) if /[*?]/;
+ @g ? @g : $_;
+ } @ARGV;
+ 1;
+ ^Z
+ C:\> set PERL5OPT=-MWild
+ C:\> perl -le "for (@ARGV) { print }" */*/perl*.c
+ p4view/perl/perl.c
+ p4view/perl/perlio.c
+ p4view/perl/perly.c
+ perl5.005/win32/perlglob.c
+ perl5.005/win32/perllib.c
+ perl5.005/win32/perlglob.c
+ perl5.005/win32/perllib.c
+ perl5.005/win32/perlglob.c
+ perl5.005/win32/perllib.c
+
+Note there are two distinct steps there: 1) You'll have to create
+Wild.pm and put it in your perl lib directory. 2) You'll need to
+set the PERL5OPT environment variable. If you want argv expansion
+to be the default, just set PERL5OPT in your default startup
+environment.
+
+If you are using the Visual C compiler, you can get the C runtime's
+command line wildcard expansion built into perl binary. The resulting
+binary will always expand unquoted command lines, which may not be
+what you want if you use a shell that does that for you. The expansion
+done is also somewhat less powerful than the approach suggested above.
+
=item Win32 Specific Extensions
A number of extensions specific to the Win32 platform are available
CPAN in source form, along with many added bugfixes, and with MakeMaker
support. This bundle is available at:
- http://www.perl.com/CPAN/authors/id/GSAR/libwin32-0.12.zip
+ http://www.perl.com/CPAN/authors/id/GSAR/libwin32-0.14.zip
See the README in that distribution for building and installation
instructions. Look for later versions that may be available at the
C<raise()>, i.e. it doesn't send a signal to the identified process
like it does on Unix platforms. Instead it immediately calls
C<TerminateProcess(process,signal)>. Thus the signal argument is
-used to set the exit-status of the terminated process. This behavior
-may change in future.
+used to set the exit-status of the terminated process. In particular,
+C<kill(0,$pid)> will kill the process identified by C<$pid> (unlike
+on Unix). This behavior may change in future.
=item *
Gary Ng E<lt>71564.1743@CompuServe.COME<gt>
-Gurusamy Sarathy E<lt>gsar@umich.eduE<gt>
+Gurusamy Sarathy E<lt>gsar@activestate.comE<gt>
Nick Ing-Simmons E<lt>nick@ni-s.u-net.comE<gt>
This port was originally contributed by Gary Ng around 5.003_24,
and borrowed from the Hip Communications port that was available
-at the time.
-
-Nick Ing-Simmons and Gurusamy Sarathy have made numerous and
-sundry hacks since then.
+at the time. Various people have made numerous and sundry hacks
+since then.
Borland support was added in 5.004_01 (Gurusamy Sarathy).
-Last updated: 12 July 1998
+GCC/mingw32 support was added in 5.005 (Nick Ing-Simmons).
-=cut
+Support for PERL_OBJECT was added in 5.005 (ActiveState Tool Corp).
+
+Support for fork() emulation was added in 5.6 (ActiveState Tool Corp).
+Win9x support was added in 5.6 (Benjamin Stuhl).
+
+Last updated: 28 December 1999
+
+=cut
https://perl5.git.perl.org / perl5.git / blobdiff