-Notes on the patch:
-~~~~~~~~~~~~~~~~~~~
-patches should be applied as
- patch -p0 <.....
-All the diff.* files and POSIX.mkfifo should be applied.
-
-Additional files are available on
- ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2
-including patched pdksh and gnumake, needed for build.
-
-
-Target:
-~~~~~~~
-
-This is not supposed to make a perfect Perl on OS/2. This patch is
-concerned only with perfect _build_ of Perl on OS/2. Some good
-features from Andreas Kaiser port missed this port. However, most of
-the features are available in different form.
-
-!!! Note that [gs]etpriority functions in this port are compatible
-!!! with *nix, not with ak's port!!!
-
-The priorities are absolute, go from 32 to -95, lower is quickier. 0
-is default,
-
-Notes on build on OS/2:
-~~~~~~~~~~~~~~~~~~~~~~~
-The change of C code in this patch is based on the ak port of 5.001+.
-
-a) Make sure your sort is not the broken OS/2 one, and that you have /tmp
-on the build partition.
-
-b) when extracting perl5.*.tar.gz you need to extract perl5.*/Configure
-separately, since by default perl5.001m/configure may overwrite it;
- like this:
- tar vzxf perl5.004.tar.gz --case-sensitive perl5.004/Configure
-
-c) Necessary manual intervention when compiling on OS/2:
-
- Need to put perl.dll on LIBPATH after it is created.
-
-d) Compile summary:
- ~~~~~~~~~~~~~~~
-!!! At the end of this README is independent description of the build
-!!! process by Rocco Caputo.
-
-# Look for hints/os2.sh and correct what is different on your system
-# I have rather spartan configuration.
-
- # Prefix means where to install:
-sh Configure -des -D prefix=f:/perl5.005
- # Ignore the message about missing `ln', and about `c' option
- # to tr.
-make
- # Will probably die after build of miniperl (unless you have DLL
- # from previous compile). Need to move DLL where it belongs
- #
- # Somehow with 5.002b3 I needed to type another make after pod2man
-make
- # some warnings in POSIX.c
-make test
- # some tests fail, 9 or 10 on my system (see the list at end).
- #
- # before this you should create subdirs bin and lib in the
- # prefix directory (f:/perl5.005 above):
- #
- # To run finer tests, cd t && perl harness
-make install
-
-e) At the end of August GNU make and pdksh were too buggy for compile.
-Both maintainers have patches that make it possible to compile perl.
-The binaries are included in
- ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2
-patches are available too.
-Note that the pdksh5.2.4 broke builds with -Zexe option because of a
-changed order of executable extensions. A patch is sent to
-maintainer. The version 5.2.5alpha was OK for the build,
-
-!!!!!!!!!!!!!!!!!
-If you see that some '/' became '\' in pdksh 5.2.3, you did not apply
-my patches!
-Same with segfaults in Make 3.74.
-!!!!!!!!!!!!!!!!!
-
-Problems reported:
-
-a) one of the latest tr is broken, get an old one :-(
- 1.11 works. (On compuserver?)
-b) You need a link386.
-c) Get rid of invalid perl.dll on your LIBPATH.
-
-Note the EMX does not support en_us locale (most nobody does ;-). Some
-TCP/IP update could have installed it to your config.sys. You need to
-delete it until EMX is updated to support this newest discovery by IBM.
-
-
-Send comments to ilya@math.ohio-state.edu.
-
-======================================================
-Requires 0.9b (well, provision are made to make it build under 0.9a6,
-but they are not tested, please inform me on success).
-(earlier than 0.9b ttyname was not present, it is hard to maintain this
-difference automatically, though I try).
-======================================================
-
-Building with a.out style is supported by the `perl_' target of make.
-Dynamic extensions are not possible with perl_.exe, since boot code
-should return the retvalue on stack, the address of which is not known
-to the extension.
-
-The reason why compiling with a.out style executables leads to problems
-with dynamic extensions is:
- a) OS/2 does not export symbols from executables;
- b) Thus if extension needs to import symbols from an application
- the symbols for the application should reside in a .dll.
- c) You cannot export data from a .dll compiled with a.out style.
-On the other hand, aout-style compiled extension enjoys all the
-(dis)advantages of fork().
-
-Check A.OUT compile with the following make targets:
-
- aout_test
- aout_install
- aout_clean
-
-======================================================
-Tests which fail with OMF compile:
-
-io/fs.t: 2-5, 7-11, 18 as they should.
-io/pipe: all, since open("|-") is not working (works with perl_.exe).
-lib/"all the dbm".t: 1 test should fail (file permission).
-op/fork all fail, as they should (except with perl_.exe)
-op/stat 3 20 35 as they should, 39 (-t on /dev/null) ???? Sometimes 4
-- timing problem ????
-
-Sometimes I have seen segfault in socket ????, only if run with Testing tools.
+The target is to make OS/2 the best supported platform for
+using/building/developping Perl and I<Perl applications>, as well as
+make Perl the best language to use under OS/2.
+
+The current state is quite close to this target. Known limitations:
+
+=over 5
+
+=item *
+
+Some *nix programs use fork() a lot, but currently fork() is not
+supported after I<use>ing dynamically loaded extensions.
+
+=item *
+
+You need a separate perl executable F<perl__.exe> (see L<perl__.exe>)
+to use PM code in your application (like the forthcoming Perl/Tk).
+
+=item *
+
+There is no simple way to access B<WPS> objects. The only way I know
+is via C<OS2::REXX> extension (see L<OS2::REXX>), and we do not have access to
+convinience methods of B<Object REXX>. (Is it possible at all? I know
+of no B<Object-REXX> API.)
+
+=back
+
+Please keep this list up-to-date by informing me about other items.
+
+=head2 Other OSes
+
+Since OS/2 port of perl uses a remarkable B<EMX> environment, it can
+run (and build extensions, and - possibly - be build itself) under any
+environment which can run EMX. The current list is DOS,
+DOS-inside-OS/2, Win0.31, Win0.95 and WinNT. Out of many perl flavors,
+only one works, see L<"perl_.exe">.
+
+Note that not all features of Perl are available under these
+environments. This depends on the features the I<extender> - most
+probably C<RSX> - decided to implement.
+
+Cf. L<Prerequisites>.
+
+=head2 Prerequisites
+
+=over 6
+
+=item B<EMX>
+
+B<EMX> runtime is required. Note that it is possible to make F<perl_.exe>
+to run under DOS without any external support by binding F<emx.exe> to
+it, see L<emxbind>.
+
+Only the latest runtime is supported, currently C<0.9c>.
+
+One can get different parts of B<EMX> from, say
+
+ ftp://ftp.cdrom.com/pub/os2/emx0.9c/
+ ftp://hobbes.nmsu.edu/os2/unix/gnu/
+
+The runtime component should have the name F<emxrt.zip>.
+
+=item B<RSX>
+
+To run Perl on C<DPMS> platforms one needs B<RSX> runtime. This is
+needed under DOS-inside-OS/2, Win0.31, Win0.95 and WinNT (see
+L<"Other OSes">).
+
+One can get B<RSX> from, say
+
+ ftp://ftp.cdrom.com/pub/os2/emx0.9c/contrib
+ ftp://ftp.uni-bielefeld.de/pub/systems/msdos/misc
+
+Contact the author on C<rainer@mathematik.uni-bielefeld.de>.
+
+=item B<HPFS>
+
+Perl does not care about file systems, but to install the whole perl
+library intact one needs a file system which supports long file names.
+
+Note that if you do not plan to build the perl itself, it may be
+possible to fool B<EMX> to truncate file names. This is not supported,
+read B<EMX> docs to see how to do it.
+
+=back
+
+=head2 Starting Perl programs under OS/2
+
+Start your Perl program F<foo.pl> with arguments C<arg1 arg2 arg3> the
+same way as on any other platform, by
+
+ perl foo.pl arg1 arg2 arg3
+
+If you want to specify perl options C<-my_opts> to the perl itself (as
+opposed to to your program), use
+
+ perl -my_opts foo.pl arg1 arg2 arg3
+
+Alternately, if you use OS/2-ish shell, like C<CMD> or C<4os2>, put
+the following at the start of your perl script:
+
+ extproc perl -x -S
+ #!/usr/bin/perl -my_opts
+
+rename your program to F<foo.cmd>, and start it by typing
+
+ foo arg1 arg2 arg3
+
+(Note that having *nixish full path to perl F</usr/bin/perl> is not
+necessary, F<perl> would be enough, but having full path would make it
+easier to use your script under *nix.)
+
+Note that because of stupid OS/2 limitations the full path of the perl
+script is not available when you use C<extproc>, thus you are forced to
+use C<-S> perl switch, and your script should be on path. As a plus
+side, if you know a full path to your script, you may still start it
+with
+
+ perl -x ../../blah/foo.cmd arg1 arg2 arg3
+
+(note that the argument C<-my_opts> is taken care of by the C<#!> line
+in your script).
+
+To understand what the above I<magic> does, read perl docs about C<-S>
+and C<-x> switches - see L<perlrun>, and cmdref about C<extproc>:
+
+ view perl perlrun
+ man perlrun
+ view cmdref extproc
+ help extproc
+
+or whatever method you prefer.
+
+There are also endless possibilites to use I<executable extensions> of
+B<4OS2>, I<associations> of B<WPS> and so on... However, if you use
+*nixish shell (like F<sh.exe> supplied in the binary distribution),
+you need follow the syntax specified in L<perlrun/"Switches">.
+
+=head2 Starting OS/2 programs under Perl
+
+This is what system() (see L<perlfunc/system>), C<``> (see
+L<perlop/"I/O Operators">), and I<open pipe> (see L<perlfunc/open>)
+are for. (Avoid exec() (see L<perlfunc/exec>) unless you know what you
+do).
+
+Note however that to use some of these operators you need to have a
+C<sh>-syntax shell installed (see L<"Pdksh">,
+L<"Frequently asked questions">), and perl should be able to find it
+(see L<"PERL_SH_DIR">).
+
+The only cases when the shell is not used is the multi-argument
+system() (see L<perlfunc/system>)/exec() (see L<perlfunc/exec>), and
+one-argument version thereof without redirection and shell
+meta-characters.
+
+=head1 Frequently asked questions
+
+=head2 I cannot run extenal programs
+
+Did you run your programs with C<-w> switch? See
+L<Starting OS/2 programs under Perl>.
+
+=head2 I cannot embed perl into my program, or use F<perl.dll> from my
+program.
+
+=over 4
+
+=item Is your program B<EMX>-compiled with C<-Zmt -Zcrtdll>?
+
+If not, you need to build a stand-alone DLL for perl. Contact me, I
+did it once. Sockets would not work, as a lot of other stuff.
+
+=item Did you use C<ExtUtils::Embed>?
+
+I had reports it does not work. Somebody would need to fix it.
+
+=back
+
+=head1 INSTALLATION
+
+=head2 Automatic binary installation
+
+The most convinient way of installing perl is via perl installer
+F<install.exe>. Just follow the instructions, and 99% of the
+installation blues would go away.
+
+Note however, that you need to have F<unzip.exe> on your path, and
+B<EMX> environment I<running>. The latter means that if you just
+installed B<EMX>, and made all the needed changes to F<Config.sys>,
+you may need to reboot in between. Check B<EMX> runtime by running
+
+ emxrev
+
+A folder is created on your desktop which contains some useful
+objects.
+
+B<Things not taken care of by automatic binary installation:>
+
+=over 15
+
+=item C<PERL_BADLANG>
+
+may be needed if you change your codepage I<after> perl installation,
+and the new value is not supported by B<EMX>. See L<"PERL_BADLANG">.
+
+=item C<PERL_BADFREE>
+
+see L<"PERL_BADFREE">.
+
+=item F<Config.pm>
+
+This file resides somewhere deep in the location you installed your
+perl library, find it out by
+
+ perl -MConfig -le "print $INC{'Config.pm'}"
+
+While most important values in this file I<are> updated by the binary
+installer, some of them may need to be hand-edited. I know no such
+data, please keep me informed if you find one.
+
+=back
+
+=head2 Manual binary installation
+
+As of version 5.00305, OS/2 perl binary distribution comes splitted
+into 11 components. Unfortunately, to enable configurable binary
+installation, the file paths in the C<zip> files are not absolute, but
+relative to some directory.
+
+Note that the extraction with the stored paths is still necessary
+(default with C<unzip>, specify C<-d> to C<pkunzip>). However, you
+need to know where to extract the files. You need also to manually
+change entries in F<Config.sys> to reflect where did you put the
+files.
+
+Below is the sample of what to do to reproduce the configuration on my
+machine:
+
+=over 3
+
+=item Perl VIO and PM executables (dynamically linked)
+
+ unzip perl_exc.zip *.exe *.ico -d f:/emx.add/bin
+ unzip perl_exc.zip *.dll -d f:/emx.add/dll
+
+(have the directories with C<*.exe> on C<PATH>, and C<*.dll> on
+C<LIBPATH>);
+
+=item Perl_ VIO executable (statically linked)
+
+ unzip perl_aou.zip -d f:/emx.add/bin
+
+(have the directory on C<PATH>);
+
+=item Executables for Perl utilities
+
+ unzip perl_utl.zip -d f:/emx.add/bin
+
+(have the directory on C<PATH>);
+
+=item Main Perl library
+
+ unzip perl_mlb.zip -d f:/perllib/lib
+
+If this directory is preserved, you do not need to change
+anything. However, for perl to find it if it is changed, you need to
+C<set PERLLIB_PREFIX> in F<Config.sys>, see L<"PERLLIB_PREFIX">.
+
+=item Additional Perl modules
+
+ unzip perl_ste.zip -d f:/perllib/lib/site_perl
+
+If you do not change this directory, do nothing. Otherwise put this
+directory and subdirectory F<./os2> in C<PERLLIB> or C<PERL5LIB>
+variable. Do not use C<PERL5LIB> unless you have it set already. See
+L<perl/"ENVIRONMENT">.
+
+=item Tools to compile Perl modules
+
+ unzip perl_blb.zip -d f:/perllib/lib
+
+If this directory is preserved, you do not need to change
+anything. However, for perl to find it if it is changed, you need to
+C<set PERLLIB_PREFIX> in F<Config.sys>, see L<"PERLLIB_PREFIX">.
+
+=item Manpages for Perl and utilities
+
+ unzip perl_man.zip -d f:/perllib/man
+
+This directory should better be on C<MANPATH>. You need to have a
+working C<man> to access these files.
+
+=item Manpages for Perl modules
+
+ unzip perl_mam.zip -d f:/perllib/man
+
+This directory should better be on C<MANPATH>. You need to have a
+working C<man> to access these files.
+
+=item Source for Perl documentation
+
+ unzip perl_pod.zip -d f:/perllib/lib
+
+This is used by by C<perldoc> program (see L<perldoc>), and may be used to
+generate B<HTML> documentation usable by WWW browsers, and
+documentation in zillions of other formats: C<info>, C<LaTeX>,
+C<Acrobat>, C<FrameMaker> and so on.
+
+=item Perl manual in .INF format
+
+ unzip perl_inf.zip -d d:/os2/book
+
+This directory should better be on C<BOOKSHELF>.
+
+=item Pdksh
+
+ unzip perl_sh.zip -d f:/bin
+
+This is used by perl to run external commands which explicitely
+require shell, like the commands using I<redirection> and I<shell
+metacharacters>. It is also used instead of explicit F</bin/sh>.
+
+Set C<PERL_SH_DIR> (see L<"PERL_SH_DIR">) if you move F<sh.exe> from
+the above location.
+
+B<Note.> It may be possible to use some other C<sh>-compatible shell
+(I<not tested>).
+
+=back
+
+After you installed the components you needed and updated the
+F<Config.sys> correspondingly, you need to hand-edit
+F<Config.pm>. This file resides somewhere deep in the location you
+installed your perl library, find it out by
+
+ perl -MConfig -le "print $INC{'Config.pm'}"
+
+You need to correct all the entries which look like file paths (they
+currently start with C<f:/>).
+
+=head2 B<Warning>
+
+The automatic and manual perl installation leave precompiled paths
+inside perl executables. While these paths are overwriteable (see
+L<"PERLLIB_PREFIX">, L<"PERL_SH_DIR">), one may get better results by
+binary editing of paths inside the executables/DLLs.
+
+=head1 Accessing documentation
+
+Depending on how you built/installed perl you may have (otherwise
+identical) Perl documentation in the following formats:
+
+=head2 OS/2 F<.INF> file
+
+Most probably the most convinient form. View it as
+
+ view perl
+ view perl perlfunc
+ view perl less
+ view perl ExtUtils::MakeMaker
+
+(currently the last two may hit a wrong location, but this may improve
+soon).
+
+If you want to build the docs yourself, and have I<OS/2 toolkit>, run
+
+ pod2ipf > perl.ipf
+
+in F</perllib/lib/pod> directory, then
+
+ ipfc /inf perl.ipf
+
+(Expect a lot of errors during the both steps.) Now move it on your
+BOOKSHELF path.
+
+=head2 Plain text
+
+If you have perl documentation in the source form, perl utilities
+installed, and B<GNU> C<groff> installed, you may use
+
+ perldoc perlfunc
+ perldoc less
+ perldoc ExtUtils::MakeMaker
+
+to access the perl documention in the text form (note that you may get
+better results using perl manpages).
+
+Alternately, try running pod2text on F<.pod> files.
+
+=head2 Manpages
+
+If you have C<man> installed on your system, and you installed perl
+manpages, use something like this:
+
+ man perlfunc
+ man 3 less
+ man ExtUtils.MakeMaker
+
+to access documentation for different components of Perl. Start with
+
+ man perl
+
+Note that dot (F<.>) is used as a package separator for documentation
+for packages, and as usual, sometimes you need to give the section - C<3>
+above - to avoid shadowing by the I<less(1) manpage>.
+
+Make sure that the directory B<above> the directory with manpages is
+on our C<MANPATH>, like this
+
+ set MANPATH=c:/man;f:/perllib/man
+
+=head2 B<HTML>
+
+If you have some WWW browser available, installed the Perl
+documentation in the source form, and Perl utilities, you can build
+B<HTML> docs. Cd to directory with F<.pod> files, and do like this
+
+ cd f:/perllib/lib/pod
+ pod2html
+
+After this you can direct your browser the file F<perl.html> in this
+directory, and go ahead with reading docs, like this:
+
+ explore file:///f:/perllib/lib/pod/perl.html
+
+Alternatively you may be able to get these docs prebuild from C<CPAN>.
+
+=head2 B<GNU> C<info> files
+
+Users of C<Emacs> would appreciate it very much, especially with
+C<CPerl> mode loaded. You need to get latest C<pod2info> from C<CPAN>,
+or, alternately, prebuilt info pages.
+
+=head2 F<.PDF> files
+
+for C<Acrobat> are available on CPAN (for slightly old version of
+perl).
+
+=head2 C<LaTeX> docs
+
+can be constructed using C<pod2latex>.
+
+=head1 BUILD
+
+Here we discuss how to build Perl under OS/2. There is an alternative
+(but maybe older) view on L<http://www.shadow.net/~troc/os2perl.html>.
+
+=head2 Prerequisites
+
+You need to have the latest B<EMX> development environment, the full
+B<GNU> tool suite (C<gawk> renamed to C<awk>, and B<GNU> F<find.exe>
+earlier on path than the OS/2 F<find.exe>, same with F<sort.exe>, to
+check use
+
+ find --version
+ sort --version
+
+). You need the latest version of F<pdksh> installed as F<sh.exe>.
+
+Possible locations to get this from are
+
+ ftp://hobbes.nmsu.edu/os2/unix/gnu/
+ ftp://ftp.cdrom.com/pub/os2/unix/
+ ftp://ftp.cdrom.com/pub/os2/dev32/
+ ftp://ftp.cdrom.com/pub/os2/emx0.9c/
+
+
+Make sure that no copies or perl are currently running. Later steps
+of the build may fail since an older version of perl.dll loaded into
+memory may be found.
+
+Also make sure that you have F</tmp> directory on the current drive,
+and F<.> directory in your C<LIBPATH>. One may try to correct the
+latter condition by
+
+ set BEGINLIBPATH .
+
+if you use something like F<CMD.EXE> or latest versions of F<4os2.exe>.
+
+Make sure your C<gcc> is good for C<-Zomf> linking: run C<omflibs>
+script in F</emx/lib> directory.
+
+Check that you have C<link386> installed. It comes standard with OS/2,
+but may be not installed due to customization. If typing
+
+ link386
+
+shows you do not have it, do I<Selective install>, and choose C<Link
+object modules> in I<Optional system utilites/More>. If you get into
+C<link386>, press C<Ctrl-C>.
+
+=head2 Getting perl source
+
+You need to fetch the latest perl source (including developpers
+releases). With some probability it is located in
+
+ http://www.perl.com/CPAN/src/5.0
+ http://www.perl.com/CPAN/src/5.0/unsupported
+
+If not, you may need to dig in the indices to find it in the directory
+of the current maintainer.
+
+Quick cycle of developpers release may break the OS/2 build time to
+time, looking into
+
+ http://www.perl.com/CPAN/ports/os2/ilyaz/
+
+may indicate the latest release which was publicly released by the
+maintainer. Note that the release may include some additional patches
+to apply to the current source of perl.
+
+Extract it like this
+
+ tar vzxf perl5.00409.tar.gz
+
+You may see a message about errors while extracting F<Configure>. This is
+because there is a conflict with a similarly-named file F<configure>.
+
+Rename F<configure> to F<configure.gnu>. Extract F<Configure> like this
+
+ tar --case-sensitive -vzxf perl5.00409.tar.gz perl5.00409/Configure
+
+Change to the directory of extraction.
+
+=head2 Application of the patches
+
+You need to apply the patches in F<./os2/diff.*> and
+F<./os2/POSIX.mkfifo> like this:
+
+ gnupatch -p0 < os2\POSIX.mkfifo
+ gnupatch -p0 < os2\os2\diff.configure
+
+You may also need to apply the patches supplied with the binary
+distribution of perl.
+
+Note also that the F<db.lib> and F<db.a> from the B<EMX> distribution
+are not suitable for multi-threaded compile (note that currently perl
+is not multithreaded, but is compiled as multithreaded for
+compatibility with B<XFree86>-OS/2). Get a corrected one from
+
+ ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2/db_mt.zip
+
+=head2 Hand-editing
+
+You may look into the file F<./hints/os2.sh> and correct anything
+wrong you find there. I do not expect it is needed anywhere.
+
+=head2 Making
+
+ sh Configure -des -D prefix=f:/perllib
+
+Prefix means where to install the resulting perl library. Giving
+correct prefix you may avoid the need to specify C<PERLLIB_PREFIX>,
+see L<"PERLLIB_PREFIX">.
+
+I<Ignore the message about missing C<ln>, and about C<-c> option to
+C<tr>>. In fact if you can trace where the latter spurious warning
+comes from, please inform me.
+
+Now
+
+ make
+
+At some moment the built may die, reporting a I<version mismatch> or
+I<unable to run F<perl>>. This means that most of the build has been
+finished, and it is the time to move the constructed F<perl.dll> to
+some I<absolute> location in C<LIBPATH>. After this done the build
+should finish without a lot of fuss. I<One can avoid it if one has the
+correct prebuilt version of F<perl.dll> on C<LIBPATH>.>
+
+Warnings which are safe to ignore: I<mkfifo() redefined> inside
+F<POSIX.c>.
+
+=head2 Testing
+
+Now run
+
+ make test
+
+Some tests (4..6) should fail. Some perl invocations should end in a
+segfault (system error C<SYS3175>). To get finer error reports,
+
+ cd t
+ perl -I ../lib harness
+
+The report you get may look like
+
+ Failed Test Status Wstat Total Fail Failed List of failed
+ ---------------------------------------------------------------
+ io/fs.t 26 11 42.31% 2-5, 7-11, 18, 25
+ lib/io_pipe.t 3 768 6 ?? % ??
+ lib/io_sock.t 3 768 5 ?? % ??
+ op/stat.t 56 5 8.93% 3-4, 20, 35, 39
+ Failed 4/118 test scripts, 96.61% okay. 27/2445 subtests failed, 98.90% okay.
+
+Note that using `make test' target two more tests may fail: C<op/exec:1>
+because of (mis)feature of C<pdksh>, and C<lib/posix:15>, which checks
+that the buffers are not flushed on C<_exit>.
+
+The reasons for failed tests are:
+
+=over 8
+
+=item F<io/fs.t>
+
+Checks I<file system> operations. Tests:
+
+=over 10
+
+=item 2-5, 7-11
+
+Check C<link()> and C<inode count> - nonesuch under OS/2.
+
+=item 18
+
+Checks C<atime> and C<mtime> of C<stat()> - I could not understand this test.
+
+=item 25
+
+Checks C<truncate()> on a filehandle just opened for write - I do not
+know why this should or should not work.
+
+=back
+
+=item F<lib/io_pipe.t>
+
+Checks C<IO::Pipe> module. Some feature of B<EMX> - test fork()s with
+dynamic extension loaded - unsupported now.
+
+=item F<lib/io_sock.t>
+
+Checks C<IO::Socket> module. Some feature of B<EMX> - test fork()s
+with dynamic extension loaded - unsupported now.
+
+=item F<op/stat.t>
+
+Checks C<stat()>. Tests:
+
+=over 4
+
+=item 3
+
+Checks C<inode count> - nonesuch under OS/2.
+
+=item 4
+
+Checks C<mtime> and C<ctime> of C<stat()> - I could not understand this test.
+
+=item 20
+
+Checks C<-x> - determined by the file extension only under OS/2.
+
+=item 35
+
+Needs F</usr/bin>.
+
+=item 39
+
+Checks C<-t> of F</dev/null>. Should not fail!
+
+=back
+
+=back
+
+In addition to errors, you should get a lot of warnings.
+
+=over 4
+
+=item A lot of `bad free'
+
+in databases related to Berkeley DB. This is a confirmed bug of
+DB. You may disable this warnings, see L<"PERL_BADFREE">.
+
+=item Process terminated by SIGTERM/SIGINT
+
+This is a standard message issued by OS/2 applications. *nix
+applications die in silence. It is considered a feature. One can
+easily disable this by appropriate sighandlers.
+
+However the test engine bleeds these message to screen in unexpected
+moments. Two messages of this kind I<should> be present during
+testing.
+
+=item F<*/sh.exe>: ln: not found
+
+=item C<ls>: /dev: No such file or directory
+
+The last two should be self-explanatory. The test suite discovers that
+the system it runs on is not I<that much> *nixish.
+
+=back
https://perl5.git.perl.org / perl5.git / blobdiff