1 |
Compiling PCRE on non-Unix systems
|
2 |
----------------------------------
|
3 |
|
4 |
This document contains the following sections:
|
5 |
|
6 |
General
|
7 |
Generic instructions for the PCRE C library
|
8 |
The C++ wrapper functions
|
9 |
Building for virtual Pascal
|
10 |
Stack size in Windows environments
|
11 |
Linking programs in Windows environments
|
12 |
Comments about Win32 builds
|
13 |
Building PCRE on Windows with CMake
|
14 |
Use of relative paths with CMake on Windows
|
15 |
Testing with RunTest.bat
|
16 |
Building under Windows with BCC5.5
|
17 |
Building PCRE on OpenVMS
|
18 |
Building PCRE on Stratus OpenVOS
|
19 |
|
20 |
|
21 |
GENERAL
|
22 |
|
23 |
I (Philip Hazel) have no experience of Windows or VMS sytems and how their
|
24 |
libraries work. The items in the PCRE distribution and Makefile that relate to
|
25 |
anything other than Unix-like systems are untested by me.
|
26 |
|
27 |
There are some other comments and files (including some documentation in CHM
|
28 |
format) in the Contrib directory on the FTP site:
|
29 |
|
30 |
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Contrib
|
31 |
|
32 |
If you want to compile PCRE for a non-Unix system (especially for a system that
|
33 |
does not support "configure" and "make" files), note that the basic PCRE
|
34 |
library consists entirely of code written in Standard C, and so should compile
|
35 |
successfully on any system that has a Standard C compiler and library. The C++
|
36 |
wrapper functions are a separate issue (see below).
|
37 |
|
38 |
The PCRE distribution includes a "configure" file for use by the Configure/Make
|
39 |
build system, as found in many Unix-like environments. There is also support
|
40 |
support for CMake, which some users prefer, especially in Windows environments.
|
41 |
There are some instructions for CMake under Windows in the section entitled
|
42 |
"Building PCRE with CMake" below. CMake can also be used to build PCRE in
|
43 |
Unix-like systems.
|
44 |
|
45 |
|
46 |
GENERIC INSTRUCTIONS FOR THE PCRE C LIBRARY
|
47 |
|
48 |
The following are generic comments about building the PCRE C library "by hand".
|
49 |
|
50 |
(1) Copy or rename the file config.h.generic as config.h, and edit the macro
|
51 |
settings that it contains to whatever is appropriate for your environment.
|
52 |
In particular, if you want to force a specific value for newline, you can
|
53 |
define the NEWLINE macro. When you compile any of the PCRE modules, you
|
54 |
must specify -DHAVE_CONFIG_H to your compiler so that config.h is included
|
55 |
in the sources.
|
56 |
|
57 |
An alternative approach is not to edit config.h, but to use -D on the
|
58 |
compiler command line to make any changes that you need to the
|
59 |
configuration options. In this case -DHAVE_CONFIG_H must not be set.
|
60 |
|
61 |
NOTE: There have been occasions when the way in which certain parameters
|
62 |
in config.h are used has changed between releases. (In the configure/make
|
63 |
world, this is handled automatically.) When upgrading to a new release,
|
64 |
you are strongly advised to review config.h.generic before re-using what
|
65 |
you had previously.
|
66 |
|
67 |
(2) Copy or rename the file pcre.h.generic as pcre.h.
|
68 |
|
69 |
(3) EITHER:
|
70 |
Copy or rename file pcre_chartables.c.dist as pcre_chartables.c.
|
71 |
|
72 |
OR:
|
73 |
Compile dftables.c as a stand-alone program (using -DHAVE_CONFIG_H if
|
74 |
you have set up config.h), and then run it with the single argument
|
75 |
"pcre_chartables.c". This generates a set of standard character tables
|
76 |
and writes them to that file. The tables are generated using the default
|
77 |
C locale for your system. If you want to use a locale that is specified
|
78 |
by LC_xxx environment variables, add the -L option to the dftables
|
79 |
command. You must use this method if you are building on a system that
|
80 |
uses EBCDIC code.
|
81 |
|
82 |
The tables in pcre_chartables.c are defaults. The caller of PCRE can
|
83 |
specify alternative tables at run time.
|
84 |
|
85 |
(4) Ensure that you have the following header files:
|
86 |
|
87 |
pcre_internal.h
|
88 |
ucp.h
|
89 |
|
90 |
(5) Also ensure that you have the following file, which is #included as source
|
91 |
when building a debugging version of PCRE, and is also used by pcretest.
|
92 |
|
93 |
pcre_printint.src
|
94 |
|
95 |
(6) Compile the following source files, setting -DHAVE_CONFIG_H as a compiler
|
96 |
option if you have set up config.h with your configuration, or else use
|
97 |
other -D settings to change the configuration as required.
|
98 |
|
99 |
pcre_chartables.c
|
100 |
pcre_compile.c
|
101 |
pcre_config.c
|
102 |
pcre_dfa_exec.c
|
103 |
pcre_exec.c
|
104 |
pcre_fullinfo.c
|
105 |
pcre_get.c
|
106 |
pcre_globals.c
|
107 |
pcre_info.c
|
108 |
pcre_maketables.c
|
109 |
pcre_newline.c
|
110 |
pcre_ord2utf8.c
|
111 |
pcre_refcount.c
|
112 |
pcre_study.c
|
113 |
pcre_tables.c
|
114 |
pcre_try_flipped.c
|
115 |
pcre_ucd.c
|
116 |
pcre_valid_utf8.c
|
117 |
pcre_version.c
|
118 |
pcre_xclass.c
|
119 |
|
120 |
Make sure that you include -I. in the compiler command (or equivalent for
|
121 |
an unusual compiler) so that all included PCRE header files are first
|
122 |
sought in the current directory. Otherwise you run the risk of picking up
|
123 |
a previously-installed file from somewhere else.
|
124 |
|
125 |
(7) Now link all the compiled code into an object library in whichever form
|
126 |
your system keeps such libraries. This is the basic PCRE C library. If
|
127 |
your system has static and shared libraries, you may have to do this once
|
128 |
for each type.
|
129 |
|
130 |
(8) Similarly, compile pcreposix.c (remembering -DHAVE_CONFIG_H if necessary)
|
131 |
and link the result (on its own) as the pcreposix library.
|
132 |
|
133 |
(9) Compile the test program pcretest.c (again, don't forget -DHAVE_CONFIG_H).
|
134 |
This needs the functions in the pcre and pcreposix libraries when linking.
|
135 |
It also needs the pcre_printint.src source file, which it #includes.
|
136 |
|
137 |
(10) Run pcretest on the testinput files in the testdata directory, and check
|
138 |
that the output matches the corresponding testoutput files. Note that the
|
139 |
supplied files are in Unix format, with just LF characters as line
|
140 |
terminators. You may need to edit them to change this if your system uses
|
141 |
a different convention. If you are using Windows, you probably should use
|
142 |
the wintestinput3 file instead of testinput3 (and the corresponding output
|
143 |
file). This is a locale test; wintestinput3 sets the locale to "french"
|
144 |
rather than "fr_FR", and there some minor output differences.
|
145 |
|
146 |
(11) If you want to use the pcregrep command, compile and link pcregrep.c; it
|
147 |
uses only the basic PCRE library (it does not need the pcreposix library).
|
148 |
|
149 |
|
150 |
THE C++ WRAPPER FUNCTIONS
|
151 |
|
152 |
The PCRE distribution also contains some C++ wrapper functions and tests,
|
153 |
contributed by Google Inc. On a system that can use "configure" and "make",
|
154 |
the functions are automatically built into a library called pcrecpp. It should
|
155 |
be straightforward to compile the .cc files manually on other systems. The
|
156 |
files called xxx_unittest.cc are test programs for each of the corresponding
|
157 |
xxx.cc files.
|
158 |
|
159 |
|
160 |
BUILDING FOR VIRTUAL PASCAL
|
161 |
|
162 |
A script for building PCRE using Borland's C++ compiler for use with VPASCAL
|
163 |
was contributed by Alexander Tokarev. Stefan Weber updated the script and added
|
164 |
additional files. The following files in the distribution are for building PCRE
|
165 |
for use with VP/Borland: makevp_c.txt, makevp_l.txt, makevp.bat, pcregexp.pas.
|
166 |
|
167 |
|
168 |
STACK SIZE IN WINDOWS ENVIRONMENTS
|
169 |
|
170 |
The default processor stack size of 1Mb in some Windows environments is too
|
171 |
small for matching patterns that need much recursion. In particular, test 2 may
|
172 |
fail because of this. Normally, running out of stack causes a crash, but there
|
173 |
have been cases where the test program has just died silently. See your linker
|
174 |
documentation for how to increase stack size if you experience problems. The
|
175 |
Linux default of 8Mb is a reasonable choice for the stack, though even that can
|
176 |
be too small for some pattern/subject combinations.
|
177 |
|
178 |
PCRE has a compile configuration option to disable the use of stack for
|
179 |
recursion so that heap is used instead. However, pattern matching is
|
180 |
significantly slower when this is done. There is more about stack usage in the
|
181 |
"pcrestack" documentation.
|
182 |
|
183 |
|
184 |
LINKING PROGRAMS IN WINDOWS ENVIRONMENTS
|
185 |
|
186 |
If you want to statically link a program against a PCRE library in the form of
|
187 |
a non-dll .a file, you must define PCRE_STATIC before including pcre.h,
|
188 |
otherwise the pcre_malloc() and pcre_free() exported functions will be declared
|
189 |
__declspec(dllimport), with unwanted results.
|
190 |
|
191 |
|
192 |
CALLING CONVENTIONS IN WINDOWS ENVIRONMENTS
|
193 |
|
194 |
It is possible to compile programs to use different calling conventions using
|
195 |
MSVC. Search the web for "calling conventions" for more information. To make it
|
196 |
easier to change the calling convention for the exported functions in the
|
197 |
PCRE library, the macro PCRE_CALL_CONVENTION is present in all the external
|
198 |
definitions. It can be set externally when compiling (e.g. in CFLAGS). If it is
|
199 |
not set, it defaults to empty; the default calling convention is then used
|
200 |
(which is what is wanted most of the time).
|
201 |
|
202 |
|
203 |
COMMENTS ABOUT WIN32 BUILDS (see also "BUILDING PCRE WITH CMAKE" below)
|
204 |
|
205 |
There are two ways of building PCRE using the "configure, make, make install"
|
206 |
paradigm on Windows systems: using MinGW or using Cygwin. These are not at all
|
207 |
the same thing; they are completely different from each other. There is also
|
208 |
support for building using CMake, which some users find a more straightforward
|
209 |
way of building PCRE under Windows. However, the tests are not run
|
210 |
automatically when CMake is used.
|
211 |
|
212 |
The MinGW home page (http://www.mingw.org/) says this:
|
213 |
|
214 |
MinGW: A collection of freely available and freely distributable Windows
|
215 |
specific header files and import libraries combined with GNU toolsets that
|
216 |
allow one to produce native Windows programs that do not rely on any
|
217 |
3rd-party C runtime DLLs.
|
218 |
|
219 |
The Cygwin home page (http://www.cygwin.com/) says this:
|
220 |
|
221 |
Cygwin is a Linux-like environment for Windows. It consists of two parts:
|
222 |
|
223 |
. A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing
|
224 |
substantial Linux API functionality
|
225 |
|
226 |
. A collection of tools which provide Linux look and feel.
|
227 |
|
228 |
The Cygwin DLL currently works with all recent, commercially released x86 32
|
229 |
bit and 64 bit versions of Windows, with the exception of Windows CE.
|
230 |
|
231 |
On both MinGW and Cygwin, PCRE should build correctly using:
|
232 |
|
233 |
./configure && make && make install
|
234 |
|
235 |
This should create two libraries called libpcre and libpcreposix, and, if you
|
236 |
have enabled building the C++ wrapper, a third one called libpcrecpp. These are
|
237 |
independent libraries: when you like with libpcreposix or libpcrecpp you must
|
238 |
also link with libpcre, which contains the basic functions. (Some earlier
|
239 |
releases of PCRE included the basic libpcre functions in libpcreposix. This no
|
240 |
longer happens.)
|
241 |
|
242 |
A user submitted a special-purpose patch that makes it easy to create
|
243 |
"pcre.dll" under mingw32 using the "msys" environment. It provides "pcre.dll"
|
244 |
as a special target. If you use this target, no other files are built, and in
|
245 |
particular, the pcretest and pcregrep programs are not built. An example of how
|
246 |
this might be used is:
|
247 |
|
248 |
./configure --enable-utf --disable-cpp CFLAGS="-03 -s"; make pcre.dll
|
249 |
|
250 |
Using Cygwin's compiler generates libraries and executables that depend on
|
251 |
cygwin1.dll. If a library that is generated this way is distributed,
|
252 |
cygwin1.dll has to be distributed as well. Since cygwin1.dll is under the GPL
|
253 |
licence, this forces not only PCRE to be under the GPL, but also the entire
|
254 |
application. A distributor who wants to keep their own code proprietary must
|
255 |
purchase an appropriate Cygwin licence.
|
256 |
|
257 |
MinGW has no such restrictions. The MinGW compiler generates a library or
|
258 |
executable that can run standalone on Windows without any third party dll or
|
259 |
licensing issues.
|
260 |
|
261 |
But there is more complication:
|
262 |
|
263 |
If a Cygwin user uses the -mno-cygwin Cygwin gcc flag, what that really does is
|
264 |
to tell Cygwin's gcc to use the MinGW gcc. Cygwin's gcc is only acting as a
|
265 |
front end to MinGW's gcc (if you install Cygwin's gcc, you get both Cygwin's
|
266 |
gcc and MinGW's gcc). So, a user can:
|
267 |
|
268 |
. Build native binaries by using MinGW or by getting Cygwin and using
|
269 |
-mno-cygwin.
|
270 |
|
271 |
. Build binaries that depend on cygwin1.dll by using Cygwin with the normal
|
272 |
compiler flags.
|
273 |
|
274 |
The test files that are supplied with PCRE are in Unix format, with LF
|
275 |
characters as line terminators. It may be necessary to change the line
|
276 |
terminators in order to get some of the tests to work. We hope to improve
|
277 |
things in this area in future.
|
278 |
|
279 |
|
280 |
BUILDING PCRE ON WINDOWS WITH CMAKE
|
281 |
|
282 |
CMake is an alternative configuration facility that can be used instead of the
|
283 |
traditional Unix "configure". CMake creates project files (make files, solution
|
284 |
files, etc.) tailored to numerous development environments, including Visual
|
285 |
Studio, Borland, Msys, MinGW, NMake, and Unix. The following instructions
|
286 |
were contributed by a PCRE user.
|
287 |
|
288 |
1. Install the latest CMake version available from http://www.cmake.org/, and
|
289 |
ensure that cmake\bin is on your path.
|
290 |
|
291 |
2. Unzip (retaining folder structure) the PCRE source tree into a source
|
292 |
directory such as C:\pcre.
|
293 |
|
294 |
3. Create a new, empty build directory, for example C:\pcre\build\
|
295 |
|
296 |
4. Run cmake-gui from the Shell envirornment of your build tool, for example,
|
297 |
Msys for Msys/MinGW or Visual Studio Command Prompt for VC/VC++.
|
298 |
|
299 |
5. Enter C:\pcre\pcre-xx and C:\pcre\build for the source and build
|
300 |
directories, respectively.
|
301 |
|
302 |
6. Hit the "Configure" button.
|
303 |
|
304 |
7. Select the particular IDE / build tool that you are using (Visual
|
305 |
Studio, MSYS makefiles, MinGW makefiles, etc.)
|
306 |
|
307 |
8. The GUI will then list several configuration options. This is where
|
308 |
you can enable UTF-8 support or other PCRE optional features.
|
309 |
|
310 |
9. Hit "Configure" again. The adjacent "Generate" button should now be
|
311 |
active.
|
312 |
|
313 |
10. Hit "Generate".
|
314 |
|
315 |
11. The build directory should now contain a usable build system, be it a
|
316 |
solution file for Visual Studio, makefiles for MinGW, etc. Exit from
|
317 |
cmake-gui and use the generated build system with your compiler or IDE.
|
318 |
|
319 |
|
320 |
USE OF RELATIVE PATHS WITH CMAKE ON WINDOWS
|
321 |
|
322 |
A PCRE user comments as follows:
|
323 |
|
324 |
I thought that others may want to know the current state of
|
325 |
CMAKE_USE_RELATIVE_PATHS support on Windows.
|
326 |
|
327 |
Here it is:
|
328 |
-- AdditionalIncludeDirectories is only partially modified (only the
|
329 |
first path - see below)
|
330 |
-- Only some of the contained file paths are modified - shown below for
|
331 |
pcre.vcproj
|
332 |
-- It properly modifies
|
333 |
|
334 |
I am sure CMake people can fix that if they want to. Until then one will
|
335 |
need to replace existing absolute paths in project files with relative
|
336 |
paths manually (e.g. from VS) - relative to project file location. I did
|
337 |
just that before being told to try CMAKE_USE_RELATIVE_PATHS. Not a big
|
338 |
deal.
|
339 |
|
340 |
AdditionalIncludeDirectories="E:\builds\pcre\build;E:\builds\pcre\pcre-7.5;"
|
341 |
AdditionalIncludeDirectories=".;E:\builds\pcre\pcre-7.5;"
|
342 |
|
343 |
RelativePath="pcre.h">
|
344 |
RelativePath="pcre_chartables.c">
|
345 |
RelativePath="pcre_chartables.c.rule">
|
346 |
|
347 |
|
348 |
TESTING WITH RUNTEST.BAT
|
349 |
|
350 |
1. Copy RunTest.bat into the directory where pcretest.exe has been created.
|
351 |
|
352 |
2. Edit RunTest.bat and insert a line that indentifies the relative location of
|
353 |
the pcre source, e.g.:
|
354 |
|
355 |
set srcdir=..\pcre-7.4-RC3
|
356 |
|
357 |
3. Run RunTest.bat from a command shell environment. Test outputs will
|
358 |
automatically be compared to expected results, and discrepancies will
|
359 |
identified in the console output.
|
360 |
|
361 |
4. To test pcrecpp, run pcrecpp_unittest.exe, pcre_stringpiece_unittest.exe and
|
362 |
pcre_scanner_unittest.exe.
|
363 |
|
364 |
|
365 |
BUILDING UNDER WINDOWS WITH BCC5.5
|
366 |
|
367 |
Michael Roy sent these comments about building PCRE under Windows with BCC5.5:
|
368 |
|
369 |
Some of the core BCC libraries have a version of PCRE from 1998 built in,
|
370 |
which can lead to pcre_exec() giving an erroneous PCRE_ERROR_NULL from a
|
371 |
version mismatch. I'm including an easy workaround below, if you'd like to
|
372 |
include it in the non-unix instructions:
|
373 |
|
374 |
When linking a project with BCC5.5, pcre.lib must be included before any of
|
375 |
the libraries cw32.lib, cw32i.lib, cw32mt.lib, and cw32mti.lib on the command
|
376 |
line.
|
377 |
|
378 |
|
379 |
BUILDING UNDER WINDOWS CE WITH VISUAL STUDIO 200x
|
380 |
|
381 |
Vincent Richomme sent a zip archive of files to help with this process. They
|
382 |
can be found in the file "pcre-vsbuild.zip" in the Contrib directory of the FTP
|
383 |
site.
|
384 |
|
385 |
|
386 |
BUILDING PCRE ON OPENVMS
|
387 |
|
388 |
Dan Mooney sent the following comments about building PCRE on OpenVMS. They
|
389 |
relate to an older version of PCRE that used fewer source files, so the exact
|
390 |
commands will need changing. See the current list of source files above.
|
391 |
|
392 |
"It was quite easy to compile and link the library. I don't have a formal
|
393 |
make file but the attached file [reproduced below] contains the OpenVMS DCL
|
394 |
commands I used to build the library. I had to add #define
|
395 |
POSIX_MALLOC_THRESHOLD 10 to pcre.h since it was not defined anywhere.
|
396 |
|
397 |
The library was built on:
|
398 |
O/S: HP OpenVMS v7.3-1
|
399 |
Compiler: Compaq C v6.5-001-48BCD
|
400 |
Linker: vA13-01
|
401 |
|
402 |
The test results did not match 100% due to the issues you mention in your
|
403 |
documentation regarding isprint(), iscntrl(), isgraph() and ispunct(). I
|
404 |
modified some of the character tables temporarily and was able to get the
|
405 |
results to match. Tests using the fr locale did not match since I don't have
|
406 |
that locale loaded. The study size was always reported to be 3 less than the
|
407 |
value in the standard test output files."
|
408 |
|
409 |
=========================
|
410 |
$! This DCL procedure builds PCRE on OpenVMS
|
411 |
$!
|
412 |
$! I followed the instructions in the non-unix-use file in the distribution.
|
413 |
$!
|
414 |
$ COMPILE == "CC/LIST/NOMEMBER_ALIGNMENT/PREFIX_LIBRARY_ENTRIES=ALL_ENTRIES
|
415 |
$ COMPILE DFTABLES.C
|
416 |
$ LINK/EXE=DFTABLES.EXE DFTABLES.OBJ
|
417 |
$ RUN DFTABLES.EXE/OUTPUT=CHARTABLES.C
|
418 |
$ COMPILE MAKETABLES.C
|
419 |
$ COMPILE GET.C
|
420 |
$ COMPILE STUDY.C
|
421 |
$! I had to set POSIX_MALLOC_THRESHOLD to 10 in PCRE.H since the symbol
|
422 |
$! did not seem to be defined anywhere.
|
423 |
$! I edited pcre.h and added #DEFINE SUPPORT_UTF8 to enable UTF8 support.
|
424 |
$ COMPILE PCRE.C
|
425 |
$ LIB/CREATE PCRE MAKETABLES.OBJ, GET.OBJ, STUDY.OBJ, PCRE.OBJ
|
426 |
$! I had to set POSIX_MALLOC_THRESHOLD to 10 in PCRE.H since the symbol
|
427 |
$! did not seem to be defined anywhere.
|
428 |
$ COMPILE PCREPOSIX.C
|
429 |
$ LIB/CREATE PCREPOSIX PCREPOSIX.OBJ
|
430 |
$ COMPILE PCRETEST.C
|
431 |
$ LINK/EXE=PCRETEST.EXE PCRETEST.OBJ, PCRE/LIB, PCREPOSIX/LIB
|
432 |
$! C programs that want access to command line arguments must be
|
433 |
$! defined as a symbol
|
434 |
$ PCRETEST :== "$ SYS$ROADSUSERS:[DMOONEY.REGEXP]PCRETEST.EXE"
|
435 |
$! Arguments must be enclosed in quotes.
|
436 |
$ PCRETEST "-C"
|
437 |
$! Test results:
|
438 |
$!
|
439 |
$! The test results did not match 100%. The functions isprint(), iscntrl(),
|
440 |
$! isgraph() and ispunct() on OpenVMS must not produce the same results
|
441 |
$! as the system that built the test output files provided with the
|
442 |
$! distribution.
|
443 |
$!
|
444 |
$! The study size did not match and was always 3 less on OpenVMS.
|
445 |
$!
|
446 |
$! Locale could not be set to fr
|
447 |
$!
|
448 |
=========================
|
449 |
|
450 |
|
451 |
BUILDING PCRE ON STRATUS OPENVOS
|
452 |
|
453 |
These notes on the port of PCRE to VOS (lightly edited) were supplied by
|
454 |
Ashutosh Warikoo, whose email address has the local part awarikoo and the
|
455 |
domain nse.co.in. The port was for version 7.9 in August 2009.
|
456 |
|
457 |
1. Building PCRE
|
458 |
|
459 |
I built pcre on OpenVOS Release 17.0.1at using GNU Tools 3.4a without any
|
460 |
problems. I used the following packages to build PCRE:
|
461 |
|
462 |
ftp://ftp.stratus.com/pub/vos/posix/ga/posix.save.evf.gz
|
463 |
|
464 |
Please read and follow the instructions that come with these packages. To start
|
465 |
the build of pcre, from the root of the package type:
|
466 |
|
467 |
./build.sh
|
468 |
|
469 |
2. Installing PCRE
|
470 |
|
471 |
Once you have successfully built PCRE, login to the SysAdmin group, switch to
|
472 |
the root user, and type
|
473 |
|
474 |
[ !create_dir (master_disk)>usr --if needed ]
|
475 |
[ !create_dir (master_disk)>usr>local --if needed ]
|
476 |
!gmake install
|
477 |
|
478 |
This installs PCRE and its man pages into /usr/local. You can add
|
479 |
(master_disk)>usr>local>bin to your command search paths, or if you are in
|
480 |
BASH, add /usr/local/bin to the PATH environment variable.
|
481 |
|
482 |
4. Restrictions
|
483 |
|
484 |
This port requires readline library optionally. However during the build I
|
485 |
faced some yet unexplored errors while linking with readline. As it was an
|
486 |
optional component I chose to disable it.
|
487 |
|
488 |
5. Known Problems
|
489 |
|
490 |
I ran a the test suite, but you will have to be your own judge of whether this
|
491 |
command, and this port, suits your purposes. If you find any problems that
|
492 |
appear to be related to the port itself, please let me know. Please see the
|
493 |
build.log file in the root of the package also.
|
494 |
|
495 |
|
496 |
=========================
|
497 |
Last Updated: 05 October 2009
|
498 |
****
|