summaryrefslogtreecommitdiff
path: root/cygwin32/build-instructions.steven-morlock
blob: 58d19936c3376860e9226a72fbd31ab2c2abe12a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
From comp.lang.perl.misc. The included patch, perl5.005_02.patch, implements most of the suggestions below. My observations during the build process are commented within the body of Mr. Morlock's message, set off by ******CSW******


**************************************
Subject: HOWTO: Builiding Perl under Win95/98 using Cygwin32  
Author:  Steven Morlock <newspost@morlock.net>
Date:    1998/12/21
Forum:   comp.lang.perl.misc 

If you have a desire to build Perl under Windows 95/98 using Cygnus'
Cygwin Win32 ports of the GNU development tools (Cygwin32) you might
get something out of my experience of building it.

An advantage of the versions Perl built with Cygwin32 is that Cygwin32
has a POSIX compatible library including support for the fork() function.

Steve

--
Steven Morlock
Foliage Software Systems
aka The Nerd Farm
http://www.foliage.com
==

These are the steps I took to build the latest development
version of Perl (5.005.53) under the Windows 95 & Window 98
operating system using Cygnus' Cygwin Win32 ports of the GNU
development tools.

The release of the Cygwin32 tools used was B20.1.  These tools
can be found at:

  http://sourceware.cygnus.com/cygwin

Install Cygwin32 as described on the Cygnus web site.  Additionally
you should mount /bin as described in the following document:

  http://sourceware.cygnus.com/cygwin/cygwin-ug-net/setup-mount.html

Note that the mount command shown in their example should appear on a
single line:

  mount C:/cygnus/cygwin-b20/H-i586-cygwin32/bin /bin

You must run the described build process below under the Cygwin32
'bash' shell.

In the following <PERL> will refer to the perl source/build
directory.  <INST> will refer to the perl target/install directory.

* Pre-build checklist:

  - I found that building Perl on a unmounted partition/drive other than the
    root will fail.  It appears that the double forward slash that Cygwin32
    uses to reference drives other than the root drive (typically C:) gets
    converted to a single forward slash at several points in the build process.
    I have not tried, but expect it would work, to mount the non-root drive.
    This problem held true for both the drive where the perl source were and
    the drive where the Cygwin32 binaries where located.  In the build
    described in these notes the Perl source and Cygwin32 binaries were located
    on the root drive.

  - Following the instructions in <PERL>/README.cygwin32:
*******CSW********
apply the patch, first
******************

      + Copy the contents of the <PERL>cygwin32 directory to <PERL>

      + Edit the 'ld2' & 'gcc2' scripts to reflect the build path <PERL>

      + Either move 'ld2' & 'gcc2' to a directory on your path or add
        <PERL> to you path.

  - Edit <PERL>/hints/cygwin32.sh:

      + Add the following lines to the script:
*******CSW********
the patch does this
******************
          i_stdarg='define'
          i_varargs='undef'

        This change allows us to pick up the right version of va_start().
        Cygwin32 has both a signal and double parameter versions floating
        around in their header files.

      + Remove support for dynamic linking.  I found that all DynaLoader'd
        extensions crashed during the running of the test suite.  Add or edit
        'usedl' entry to read:
*******CSW********
the patch does this
******************
          usedl='n'

        If there is enough push I will try to sort out the problems with
        dynamic loading.  I have made several unsuccessful attempts at
        modifying <PERL>/perlld to fix this problem.  If you are interested,
        write me.

      + Change the path to the  Cygwin32 directories.  This includes the
        entries for 'usrinc', 'libpth', 'lddlflags', 'libc' and 'usrinc'.
*******CSW********
the patch does this ^
******************

  - Edit makedepend.SH.  The original version of makedepend.SH produces
    dependencies that include double backslashes.  This can not be processed
    by Cygwin32's 'make'.  Apply the following modification to makedepend.SH
    to correct these unfortunate filenames:
*******CSW********
and this, as well \/
******************

*** makedepend.SH.ORIG Wed Sep 23 09:51:56 1998
--- makedepend.SH Mon Dec 21 09:27:30 1998
***************
*** 100,105 ****
--- 100,107 ----
  # for file in `cat /dev/null`; do
   if [ "$osname" = uwin ]; then
    uwinfix="-e s,\\\\\\\\,/,g -e s,\\([a-zA-Z]\\):/,/\\1/,g"
+  elif [ "$archname" = cygwin32 ]; then
+   uwinfix="-e s,\\\\\\\\,/,g"
   else
    uwinfix=
   fi

  - Edit config_h.SH. The original version of config_h.SH has an bogus
    #include that gets propagated into the dependency list in Makefile
    create from the makedepend script.  The Apply the following modification
    to config_h.SH to work around this unfortunate filename:
*******CSW********
the patch does this, too
******************

*** config_h.SH.ORIG Wed Oct 28 23:16:10 1998
--- config_h.SH Mon Dec 21 10:14:28 1998
***************
*** 1412,1416 ****
  #endif
  #if $cpp_stuff != 1 && $cpp_stuff != 42
! #include "Bletch: How does this C preprocessor catenate tokens?"
  #endif

--- 1412,1416 ----
  #endif
  #if $cpp_stuff != 1 && $cpp_stuff != 42
! #include "#Bletch: How does this C preprocessor catenate tokens?"
  #endif

    The real source of the problem appears that the 'make depend' in the
    'x2p' directory has problems.  The following messages are generated by
    that 'make depend':

      Finding dependencies for hash.o.
      gcc2: Can't open gcc2
      ... [similar messages to above]
      You don't seem to have a proper C preprocessor.  Using grep instead.
      Updating GNUmakefile...

    So the grep is pulling the bogus #include from the file.  The patch
    turns the #include'd message into a comment.

  - Run the Configure in the <PERL> directory as described in the document
    <PERL>/README.cygwin32

    I receive the message "THIS PACKAGE SEEMS INCOMPLETE.".  This does not
    appear to be a problem.

    When presented with the list of handy defaults, select 'cygwin32'

    You can use the defaults for the remainder of the prompts.

* Building:

  - Issue the command 'make' in the directory <PERL>.
    Cross fingers, wait and be patient.

*******CSW********
I didn't see this problem \/
******************
  - I experience problems when building two files 'pp_sys.o' & 'doio.o'.  The
    build process will crash with a Windows dialog during the build of these two
    files.  The way I get by the problem is to control-C the make and issue
    the build commands for the two files by hand.  In the Perl directory issue
    the following commands:

      `sh  cflags libperl.a pp_sys.o` pp_sys.c
      `sh  cflags libperl.a doio.o` doio.c

    This appears to be a problem with Cygwin32's make.

  Hopefully if you follow the instructions above you will experience no
  problems building Perl.

* Testing:

  I found that the majority of the tests passed.  There were no errors
  that I thought particularly scary.  There were several unexpected results
  such as a couple 'A required .DLL file, CYGWIN1.DLL, was not found' dialogs
  and 'Perl perform an illegal operation' dialogs.

*******CSW********
saw the "missing dll" during one test
******************

  As long as I can run all my own scripts, things are fine by me...

  - Renamed or delete the file <PERL>/t/lib/io_sock.t so it will not be
    executed.  This test hangs the system.  I have made no attempts to
    fix the problem.  From the <PERL> directory issue the following command:

*******CSW********
I didn't do this, and saw no problems.
******************

      mv t/lib/io_sock.t t/lib/io_sock.t.ORIG

  - Issue the command 'make test' in the directory <PERL>.
    Cross fingers, wait and be patient.

* Installing:

  The install seems to work okay.  There are problems when install the man
  pages, but we don't need any stinkin' man pages, right?

*******CSW********
the man pages that didn't install were those that had "::" in their filename.
******************

  - Issue the command 'make install' in the directory <PERL>.

Configuration files available by request to perl@morlock.net