perlcyg.pod

source of perl for linux application,

If you read this file _as_is_, just ignore the funny characters you
see. It is written in the POD format (see pod/perlpod.pod) which is
specially designed to be readable as is.

=head1 NAME

README.cygwin - Perl for Cygwin

=head1 SYNOPSIS

This document will help you configure, make, test and install Perl
on Cygwin.  This document also describes features of Cygwin that will
affect how Perl behaves at runtime.

B<NOTE:> There are pre-built Perl packages available for Cygwin and a
version of Perl is provided on the Cygwin CD.  If you do not need to
customize the configuration, consider using one of these packages:

  http://cygutils.netpedia.net/

=head1 PREREQUISITES

=head2 Cygwin = GNU+Cygnus+Windows (Don't leave UNIX without it)

The Cygwin tools are ports of the popular GNU development tools for Win32
platforms.  They run thanks to the Cygwin library which provides the UNIX
system calls and environment these programs expect.  More information
about this project can be found at:

  http://www.cygwin.com/

A recent net or commercial release of Cygwin is required.

At the time this document was last updated, Cygwin 1.1.5 was current.

B<NOTE:> At this point, minimal effort has been made to provide
compatibility with old (beta) Cygwin releases.  The focus has been to
provide a high quality release and not worry about working around old
bugs.  If you wish to use Perl with Cygwin B20.1 or earlier, consider
using perl5.005_03, which is available in source and binary form at
C<http://cygutils.netpedia.net/>.  If there is significant demand,
a patch kit can be developed to port back to earlier Cygwin versions.

=head2 Cygwin Configuration

While building Perl some changes may be necessary to your Cygwin setup so
that Perl builds cleanly.  These changes are B<not> required for normal
Perl usage.

B<NOTE:> The binaries that are built will run on all Win32 versions.
They do not depend on your host system (Win9x/WinME, WinNT/Win2K)
or your Cygwin configuration (I<ntea>, I<ntsec>, binary/text mounts).
The only dependencies come from hard-coded pathnames like C</usr/local>.
However, your host system and Cygwin configuration will affect Perl's
runtime behavior (see L</"TEST">).

=over 4

=item * C<PATH>

Set the C<PATH> environment variable so that Configure finds the Cygwin
versions of programs.  Any Windows directories should be removed or
moved to the end of your C<PATH>.

=item * I<nroff>

If you do not have I<nroff> (which is part of the I<groff> package),
Configure will B<not> prompt you to install I<man> pages.

=item * Permissions

On WinNT with either the I<ntea> or I<ntsec> C<CYGWIN> settings, directory
and file permissions may not be set correctly.  Since the build process
creates directories and files, to be safe you may want to run a `C<chmod
-R +w *>' on the entire Perl source tree.

Also, it is a well known WinNT "feature" that files created by a login
that is a member of the I<Administrators> group will be owned by the
I<Administrators> group.  Depending on your umask, you may find that you
can not write to files that you just created (because you are no longer
the owner).  When using the I<ntsec> C<CYGWIN> setting, this is not an
issue because it "corrects" the ownership to what you would expect on
a UNIX system.

=back

=head1 CONFIGURE

The default options gathered by Configure with the assistance of
F<hints/cygwin.sh> will build a Perl that supports dynamic loading
(which requires a shared F<libperl.dll>).

This will run Configure and keep a record:

  ./Configure 2>&1 | tee log.configure

If you are willing to accept all the defaults run Configure with B<-de>.
However, several useful customizations are available.

=head2 Strip Binaries

It is possible to strip the EXEs and DLLs created by the build process.
The resulting binaries will be significantly smaller.  If you want the
binaries to be stripped, you can either add a B<-s> option when Configure
prompts you,

  Any additional ld flags (NOT including libraries)? [none] -s
  Any special flags to pass to gcc to use dynamic linking? [none] -s
  Any special flags to pass to ld2 to create a dynamically loaded library?
  [none] -s

or you can edit F<hints/cygwin.sh> and uncomment the relevant variables
near the end of the file.

=head2 Optional Libraries

Several Perl functions and modules depend on the existence of
some optional libraries.  Configure will find them if they are
installed in one of the directories listed as being used for library
searches.  Pre-built packages for most of these are available at
C<http://cygutils.netpedia.net/>.

=over 4

=item * C<-lcrypt>

The crypt package distributed with Cygwin is a Linux compatible 56-bit
DES crypt port by Corinna Vinschen.

Alternatively, the crypt libraries in GNU libc have been ported to Cygwin.

The DES based Ultra Fast Crypt port was done by Alexey Truhan:

  ftp://ftp.franken.de/pub/win32/develop/gnuwin32/cygwin/porters/Okhapkin_Sergey/cw32crypt-dist-0.tgz

NOTE: There are various export restrictions on DES implementations,
see the glibc README for more details.

The MD5 port was done by Andy Piper:

  ftp://ftp.franken.de/pub/win32/develop/gnuwin32/cygwin/porters/Okhapkin_Sergey/libcrypt.tgz

=item * C<-lgdbm> (C<use GDBM_File>)

GDBM is available for Cygwin.  GDBM's ndbm/dbm compatibility feature
also makes C<NDBM_File> and C<ODBM_File> possible (although they add
little extra value).

NOTE: The ndbm/dbm emulations only completely work on NTFS partitions.

=item * C<-ldb> (C<use DB_File>)

BerkeleyDB is available for Cygwin.  Some details can be found in
F<ext/DB_File/DB_File.pm>.

NOTE: The BerkeleyDB library only completely works on NTFS partitions.

=item * C<-lcygipc> (C<use IPC::SysV>)

A port of SysV IPC is available for Cygwin.

NOTE: This has B<not> been extensively tested.  In particular,
C<d_semctl_semun> is undefined because it fails a Configure test
and on Win9x the I<shm*()> functions seem to hang.  It also creates
a compile time dependency because F<perl.h> includes F<<sys/ipc.h>>
and F<<sys/sem.h>> (which will be required in the future when compiling
CPAN modules).

=back

=head2 Configure-time Options

The F<INSTALL> document describes several Configure-time options.  Some of
these will work with Cygwin, others are not yet possible.  Also, some of
these are experimental.  You can either select an option when Configure
prompts you or you can define (undefine) symbols on the command line.

=over 4

=item * C<-Uusedl>

Undefining this symbol forces Perl to be compiled statically.

=item * C<-Uusemymalloc>

By default Perl uses the malloc() included with the Perl source.  If you
want to force Perl to build with the system malloc() undefine this symbol.

=item * C<-Dusemultiplicity>

Multiplicity is required when embedding Perl in a C program and using
more than one interpreter instance.  This works with the Cygwin port.

=item * C<-Duseperlio>

The PerlIO abstraction works with the Cygwin port.

=item * C<-Duse64bitint>

I<gcc> supports 64-bit integers.  However, several additional long long
functions are necessary to use them within Perl (I<{strtol,strtoul}l>).
These are B<not> yet available with Cygwin.

=item * C<-Duselongdouble>

I<gcc> supports long doubles (12 bytes).  However, several additional
long double math functions are necessary to use them within Perl
(I<{atan2,cos,exp,floor,fmod,frexp,isnan,log,modf,pow,sin,sqrt}l,strtold>).
These are B<not> yet available with Cygwin.

=item * C<-Dusethreads>

POSIX threads are B<not> yet implemented in Cygwin.

=item * C<-Duselargefiles>

Although Win32 supports large files, Cygwin currently uses 32-bit integers
for internal size and position calculations.

=back

=head2 Suspicious Warnings

You may see some messages during Configure that seem suspicious.

=over 4

=item * I<dlsym()>

I<ld2> is needed to build dynamic libraries, but it does not exist
when dlsym() checking occurs (it is not created until `C<make>' runs).
You will see the following message:

  Checking whether your dlsym() needs a leading underscore ...
  ld2: not found
  I can't compile and run the test program.
  I'm guessing that dlsym doesn't need a leading underscore.

Since the guess is correct, this is not a problem.

=item * Win9x and C<d_eofnblk>

Win9x does not correctly report C<EOF> with a non-blocking read on a
closed pipe.  You will see the following messages:

  But it also returns -1 to signal EOF, so be careful!
  WARNING: you can't distinguish between EOF and no data!

  *** WHOA THERE!!! ***
      The recommended value for $d_eofnblk on this machine was "define"!
      Keep the recommended value? [y]

At least for consistency with WinNT, you should keep the recommended
value.

=item * Compiler/Preprocessor defines

The following error occurs because of the Cygwin C<#define> of
C<_LONG_DOUBLE>:

  Guessing which symbols your C compiler and preprocessor define...
  try.c:<line#>: parse error

This failure does not seem to cause any problems.

=back

=head1 MAKE

Simply run I<make> and wait:

  make 2>&1 | tee log.make

=head2 Warnings

Warnings like these are normal:

  warning: overriding commands for target <file>
  warning: ignoring old commands for target <file>

  dllwrap: no export definition file provided
  dllwrap: creating one, but that may not be what you want

=head2 ld2

During `C<make>', I<ld2> will be created and installed in your $installbin
directory (where you said to put public executables).  It does not
wait until the `C<make install>' process to install the I<ld2> script,
this is because the remainder of the `C<make>' refers to I<ld2> without
fully specifying its path and does this from multiple subdirectories.
The assumption is that $installbin is in your current C<PATH>.  If this
is not the case `C<make>' will fail at some point.  If this happens,
just manually copy I<ld2> from the source directory to somewhere in
your C<PATH>.

=head1 TEST