/usr/perl5. Common prefixes to use are /usr/local and /opt/perl.
You may wish to put your version of perl in the PATH of all users by
-changing the symlink /usr/bin/perl. This is OK, as all Perl scripts
+changing the link /usr/bin/perl. This is OK, as all Perl scripts
shipped with Solaris use /usr/perl5/bin/perl.
=head2 Solaris Version Numbers.
=head1 RESOURCES
-There are many, many source for Solaris information. A few of the
+There are many, many sources for Solaris information. A few of the
important ones for perl:
=over 4
=item Precompiled Binaries
Precompiled binaries, links to many sites, and much, much more is
-available at L<http://www.sunfreeware.com>.
+available at L<http://www.sunfreeware.com/>.
=item Solaris Documentation
-All Solaris documentation is available on-line at L<http://docs.sun.com>.
+All Solaris documentation is available on-line at L<http://docs.sun.com/>.
=back
=head1 SETTING UP
-=head2 File Extraction Problems.
+=head2 File Extraction Problems on Solaris.
Be sure to use a tar program compiled under Solaris (not SunOS 4.x)
to extract the perl-5.x.x.tar.gz file. Do not use GNU tar compiled
When you run SunOS4 binaries on Solaris, the run-time system magically
alters pathnames matching m#lib/locale# so that when tar tries to create
lib/locale.pm, a file named lib/oldlocale.pm gets created instead.
-If you found this advice it too late and used a SunOS4-compiled tar
+If you found this advice too late and used a SunOS4-compiled tar
anyway, you must find the incorrectly renamed file and move it back
to lib/locale.pm.
-=head2 Compiler and Related Tools.
+=head2 Compiler and Related Tools on Solaris.
You must use an ANSI C compiler to build perl. Perl can be compiled
with either Sun's add-on C compiler or with gcc. The C compiler that
/usr/include/sys/errno.h f none 0644 root bin 7471 37605 956241356 SUNWhea
-You need the package SUNWhea.
+The last item listed (SUNWhea in this example) is the package you need.
=head3 Avoid /usr/ucb/cc.
Configure from even looking in /usr/ucblib for libraries, and also
explicitly omits -lucb.
-=head2 Environment
+=head2 Environment for Compiling Perl on Solaris
=head3 PATH
Only Solaris-specific issues are discussed here. Usually, the
defaults should be fine.
-=head2 64-bit Issues.
+=head2 64-bit Issues with Perl on Solaris.
See the INSTALL file for general information regarding 64-bit compiles.
In general, the defaults should be fine for most people.
CPUs, via a reboot. You can build 64 bit apps whilst running 32 bit
mode and vice-versa. 32 bit apps will run under Solaris running in
either 32 or 64 bit mode. 64 bit apps require Solaris to be running
-64 bit mode
+64 bit mode.
Existing 32 bit apps are properly known as LP32, i.e. Longs and
Pointers are 32 bit. 64-bit apps are more properly known as LP64.
and this is the default for perl-5.6.0.
For a more complete explanation of 64-bit issues, see the Solaris 64-bit
-Developer's Guide at http://docs.sun.com:80/ab2/coll.45.13/SOL64TRANS/
+Developer's Guide at L<http://docs.sun.com:80/ab2/coll.45.13/SOL64TRANS/>
You can detect the OS mode using "isainfo -v", e.g.
want to allocate more than ~ 4GB of memory inside Perl, you probably
don't need Perl to be a 64-bit app.
-=head3 Large File Suppprt
+=head3 Large File Support
For Solaris 2.6 and onwards, there are two different ways for 32-bit
applications to manipulate large files (files whose size is > 2GByte).
=head3 Building an LP64 Perl
-To compile a 64-bit application with a recent Sun Compiler, you need to
-use the flag "-xarch=v9". getconf(1) will tell you this, e.g.
+To compile a 64-bit application on an UltraSparc with a recent Sun Compiler,
+you need to use the flag "-xarch=v9". getconf(1) will tell you this, e.g.
fubar$ getconf -a | grep v9
XBS5_LP64_OFF64_CFLAGS: -xarch=v9
_XBS5_LPBIG_OFFBIG_LDFLAGS: -xarch=v9
_XBS5_LPBIG_OFFBIG_LINTFLAGS: -xarch=v9
-This flag is supported in Sun WorkShop Compilers 5.0 and onwards when
-used on Solaris 7 onwards.
+This flag is supported in Sun WorkShop Compilers 5.0 and onwards
+(now marketed under the name Forte) when used on Solaris 7 or later on
+UltraSparc systems.
If you are using gcc, you would need to use -mcpu=v9 -m64 instead. This
option is not yet supported as of gcc 2.95.2; from install/SPECIFIC
All this should be handled automatically by the hints file, if
requested.
-If you do want to be able to allocate more than 4GB memory inside
-perl, then you should use the Solaris malloc, since the perl
-malloc breaks when dealing with more than 2GB of memory. You can do
-this with
-
- sh Configure -Uusemymalloc
-
=head3 Long Doubles.
As of 5.6.0, long doubles are not working.
-=head2 Threads.
+=head2 Threads in Perl on Solaris.
It is possible to build a threaded version of perl on Solaris. The entire
perl thread implementation is still experimental, however, so beware.
to 2.6, that function is in -lposix4. Starting with Solaris 7, it is
in -lrt. The hints file should handle adding this automatically.
-=head2 Malloc Issues.
+=head2 Malloc Issues with Perl on Solaris.
+
+Starting from Perl 5.7.1 Perl uses the Solaris malloc, since the perl
+malloc breaks when dealing with more than 2GB of memory, and the Solaris
+malloc also seems to be faster.
+If you for some reason (such as binary backward compatibility) really
+need to use perl's malloc, you can rebuild Perl from the sources
+and Configure the build with
+
+ sh Configure -Dusemymalloc
+
You should not use perl's malloc if you are building with gcc. There
are reports of core dumps, especially in the PDL module. The problem
appears to go away under -DDEBUGGING, so it has been difficult to
-track down. Sun's compiler appears to be ok with or without perl's
+track down. Sun's compiler appears to be okay with or without perl's
malloc. [XXX further investigation is needed here.]
-You should also not use perl's malloc if you are building perl as
-an LP64 application, since perl's malloc has trouble allocating more
-than 2GB of memory.
-
-You can avoid perl's malloc by Configuring with
-
- sh Configure -Uusemymalloc
-
-[XXX Update hints file.]
-
=head1 MAKE PROBLEMS.
=over 4
=head1 MAKE TEST
-=head2 op/stat.t test 4
+=head2 op/stat.t test 4 in Solaris
op/stat.t test 4 may fail if you are on a tmpfs of some sort.
Building in /tmp sometimes shows this behavior. The
test suite detects if you are building in /tmp, but it may not be able
to catch all tmpfs situations.
-=head1 PREBUILT BINARIES.
+=head2 nss_delete core dump from op/pwent or op/grent
+
+See L<perlhpux/"nss_delete core dump from op/pwent or op/grent">.
+
+=head1 PREBUILT BINARIES OF PERL FOR SOLARIS.
You can pick up prebuilt binaries for Solaris from
L<http://www.sunfreeware.com/>, ActiveState L<http://www.activestate.com/>,
There are probably other sources as well. Please note that these sites
are under the control of their respective owners, not the perl developers.
-=head1 RUNTIME ISSUES.
+=head1 RUNTIME ISSUES FOR PERL ON SOLARIS.
-=head2 Limits on Numbers of Open Files.
+=head2 Limits on Numbers of Open Files on Solaris.
The stdio(3C) manpage notes that only 255 files may be opened using
fopen(), and only file descriptors 0 through 255 can be used in a
=head1 SOLARIS-SPECIFIC PROBLEMS WITH MODULES.
-=head2 Proc::ProcessTable
+=head2 Proc::ProcessTable on Solaris
Proc::ProcessTable does not compile on Solaris with perl5.6.0 and higher
if you have LARGEFILES defined. Since largefile support is the
Proc::ProcessTable doesn't try to share off_t's with the rest of perl,
or if it does they should be explicitly specified as off64_t.
-=head2 BSD::Resource
+=head2 BSD::Resource on Solaris
BSD::Resource versions earlier than 1.09 do not compile on Solaris
with perl 5.6.0 and higher, for the same reasons as Proc::ProcessTable.
BSD::Resource versions starting from 1.09 have a workaround for the problem.
-=head2 Net::SSLeay
+=head2 Net::SSLeay on Solaris
Net::SSLeay requires a /dev/urandom to be present. This device is not
part of Solaris. You can either get the package SUNWski (packaged with
=head1 LAST MODIFIED
-$Id: README.solaris,v 1.3 2000/11/09 19:11:27 doughera Exp $
+$Id: README.solaris,v 1.4 2000/11/11 20:29:58 doughera Exp $