perlhpux.html

来自「perl教程」· HTML 代码 · 共 601 行 · 第 1/3 页

  HP 9000 A-Class servers, now renamed HP Server rp2400 series.
  HP 9000 L-Class servers, now renamed HP Server rp5400 series.
  HP 9000 N-Class servers, now renamed HP Server rp7400.</pre>
<pre>
  rp2400, rp2405, rp2430, rp2450, rp2470, rp3410, rp3440, rp4410,
  rp4440, rp5400, rp5405, rp5430, rp5450, rp5470, rp7400, rp7405,
  rp7410, rp7420, rp8400, rp8420, Superdome</pre>
<p>The current naming convention is:</p>
<pre>
  aadddd
  ||||`+- 00 - 99 relative capacity &amp; newness (upgrades, etc.)
  |||`--- unique number for each architecture to ensure different
  |||     systems do not have the same numbering across
  |||     architectures
  ||`---- 1 - 9 identifies family and/or relative positioning
  ||
  |`----- c = ia32 (cisc)
  |       p = pa-risc
  |       x = ia-64 (Itanium &amp; Itanium 2)
  |       h = housing
  `------ t = tower
          r = rack optimized
          s = super scalable
          b = blade
          sa = appliance</pre>
<p>
</p>
<h2><a name="itanium_processor_family_and_hpux">Itanium Processor Family and HP-UX</a></h2>
<p>HP-UX also runs on the new Itanium processor.  This requires the use
of a different version of HP-UX (currently 11.23 or 11i v2), and with
the exception of a few differences detailed below and in later sections,
Perl should compile with no problems.</p>
<p>Although PA-RISC binaries can run on Itanium systems, you should not
attempt to use a PA-RISC version of Perl on an Itanium system.  This is
because shared libraries created on an Itanium system cannot be loaded
while running a PA-RISC executable.</p>
<p>HP Itanium 2 systems are usually refered to with model description
&quot;HP Integrity&quot;.</p>
<p>
</p>
<h2><a name="itanium___itanium_2">Itanium &amp; Itanium 2</a></h2>
<p>HP also ships servers with the 128-bit Itanium processor(s). As of the
date of this document's last update, the following systems contain
Itanium or Itanium 2 chips (this is very likely to be out of date):</p>
<pre>
  BL60p, rx1600, rx1620, rx2600, rx2600hptc, rx2620, rx4610, rx4640,
  rx5670, rx7620, rx8620, rx9610</pre>
<p>To see all about your machine, type</p>
<pre>
  # model
  ia64 hp server rx2600
  # /usr/contrib/bin/machinfo</pre>
<p>
</p>
<h2><a name="building_dynamic_extensions_on_hpux">Building Dynamic Extensions on HP-UX</a></h2>
<p>HP-UX supports dynamically loadable libraries (shared libraries).
Shared libraries end with the suffix .sl.  On Itanium systems,
they end with the suffix .so.</p>
<p>Shared libraries created on a platform using a particular PA-RISC
version are not usable on platforms using an earlier PA-RISC version by
default.  However, this backwards compatibility may be enabled using the
same +DAportable compiler flag (with the same PA-RISC 1.0 caveat
mentioned above).</p>
<p>Shared libraries created on an Itanium platform cannot be loaded on
a PA-RISC platform.  Shared libraries created on a PA-RISC platform
can only be loaded on an Itanium platform if it is a PA-RISC executable
that is attempting to load the PA-RISC library.  A PA-RISC shared
library cannot be loaded into an Itanium executable nor vice-versa.</p>
<p>To create a shared library, the following steps must be performed:</p>
<pre>
  1. Compile source modules with +z or +Z flag to create a .o module
     which contains Position-Independent Code (PIC).  The linker will
     tell you in the next step if +Z was needed.
     (For gcc, the appropriate flag is -fpic or -fPIC.)</pre>
<pre>
  2. Link the shared library using the -b flag.  If the code calls
     any functions in other system libraries (e.g., libm), it must
     be included on this line.</pre>
<p>(Note that these steps are usually handled automatically by the extension's
Makefile).</p>
<p>If these dependent libraries are not listed at shared library creation
time, you will get fatal &quot;Unresolved symbol&quot; errors at run time when the
library is loaded.</p>
<p>You may create a shared library that refers to another library, which
may be either an archive library or a shared library.  If this second
library is a shared library, this is called a &quot;dependent library&quot;.  The
dependent library's name is recorded in the main shared library, but it
is not linked into the shared library.  Instead, it is loaded when the
main shared library is loaded.  This can cause problems if you build an
extension on one system and move it to another system where the
libraries may not be located in the same place as on the first system.</p>
<p>If the referred library is an archive library, then it is treated as a
simple collection of .o modules (all of which must contain PIC).  These
modules are then linked into the shared library.</p>
<p>Note that it is okay to create a library which contains a dependent
library that is already linked into perl.</p>
<p>Some extensions, like DB_File and Compress::Zlib use/require prebuilt
libraries for the perl extensions/modules to work. If these libraries
are built using the default configuration, it might happen that you
run into an error like &quot;invalid loader fixup&quot; during load phase.
HP is aware of this problem.  Search the HP-UX cxx-dev forums for
discussions about the subject.  The short answer is that <strong>everything</strong>
(all libraries, everything) must be compiled with <code>+z</code> or <code>+Z</code> to be
PIC (position independent code).  (For gcc, that would be
<code>-fpic</code> or <code>-fPIC</code>).  In HP-UX 11.00 or newer the linker
error message should tell the name of the offending object file.</p>
<p>A more general approach is to intervene manually, as with an example for
the DB_File module, which requires SleepyCat's libdb.sl:</p>
<pre>
  # cd .../db-3.2.9/build_unix
  # vi Makefile
  ... add +Z to all cflags to create shared objects
  CFLAGS=         -c $(CPPFLAGS) +Z -Ae +O2 +Onolimit \
                  -I/usr/local/include -I/usr/include/X11R6
  CXXFLAGS=       -c $(CPPFLAGS) +Z -Ae +O2 +Onolimit \
                  -I/usr/local/include -I/usr/include/X11R6</pre>
<pre>
  <span class="comment"># make clean</span>
  <span class="comment"># make</span>
  <span class="comment"># mkdir tmp</span>
  <span class="comment"># cd tmp</span>
  <span class="comment"># ar x ../libdb.a</span>
  <span class="comment"># ld -b -o libdb-3.2.sl *.o</span>
  <span class="comment"># mv libdb-3.2.sl /usr/local/lib</span>
  <span class="comment"># rm *.o</span>
  <span class="comment"># cd /usr/local/lib</span>
  <span class="comment"># rm -f libdb.sl</span>
  <span class="comment"># ln -s libdb-3.2.sl libdb.sl</span>
</pre>
<pre>
  <span class="comment"># cd .../DB_File-1.76</span>
  <span class="comment"># make distclean</span>
  <span class="comment"># perl Makefile.PL</span>
  <span class="comment"># make</span>
  <span class="comment"># make test</span>
  <span class="comment"># make install</span>
</pre>
<p>As of db-4.2.x it is no longer needed to do this by hand. Sleepycat
has changed the configuration process to add +z on HP-UX automatically.</p>
<pre>
  <span class="comment"># cd .../db-4.2.25/build_unix</span>
  <span class="comment"># env CFLAGS=+DA2.0w LDFLAGS=+DA2.0w ../dist/configure</span>
</pre>
<p>should work to generate 64bit shared libraries for HP-UX 11.00 and 11i.</p>
<p>It is no longer possible to link PA-RISC 1.0 shared libraries (even
though the command-line flags are still present).</p>
<p>PA-RISC and Itanium object files are not interchangeable.  Although
you may be able to use ar to create an archive library of PA-RISC
object files on an Itanium system, you cannot link against it using
an Itanium link editor.</p>
<p>
</p>
<h2><a name="the_hp_ansi_c_compiler">The HP ANSI C Compiler</a></h2>
<p>When using this compiler to build Perl, you should make sure that the
flag -Aa is added to the cpprun and cppstdin variables in the config.sh
file (though see the section on 64-bit perl below). If you are using a
recent version of the Perl distribution, these flags are set automatically.</p>
<p>
</p>
<h2><a name="the_gnu_c_compiler">The GNU C Compiler</a></h2>
<p>When you are going to use the GNU C compiler (gcc), and you don't have
gcc yet, you can either build it yourself from the sources (available
from e.g. <a href="http://www.gnu.ai.mit.edu/software/gcc/releases.html)">http://www.gnu.ai.mit.edu/software/gcc/releases.html)</a> or fetch
a prebuilt binary from the HP porting center. There are two places where
gcc prebuilds can be fetched; the first and best (for HP-UX 11 only) is
<a href="http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,547,00.html">http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,547,00.html</a>
the second is <a href="http://hpux.cs.utah.edu/hppd/hpux/Gnu/">http://hpux.cs.utah.edu/hppd/hpux/Gnu/</a> where you can also
find the GNU binutils package. (Browse through the list, because there
are often multiple versions of the same package available).</p>
<p>Above mentioned distributions are depots. H.Merijn Brand has made prebuilt
gcc binaries available on <a href="http://mirrors.develooper.com/hpux/">http://mirrors.develooper.com/hpux/</a> and/or
<a href="http://www.cmve.net/~merijn/">http://www.cmve.net/~merijn/</a> for HP-UX 10.20, HP-UX 11.00, and HP-UX 11.11
(HP-UX 11i) in both 32- and 64-bit versions. These are bzipped tar archives
that also include recent GNU binutils and GNU gdb.  Read the instructions
on that page to rebuild gcc using itself.</p>
<p>On PA-RISC you need a different compiler for 32-bit applications and for
64-bit applications. On PA-RISC, 32-bit objects and 64-bit objects do
not mix. Period. There is no different behaviour for HP C-ANSI-C or GNU
gcc. So if you require your perl binary to use 64-bit libraries, like
Oracle-64bit, you MUST build a 64-bit perl.</p>
<p>Building a 64-bit capable gcc on PA-RISC from source is possible only when
you have the HP C-ANSI C compiler or an already working 64-bit binary of
gcc available. Best performance for perl is achieved with HP's native
compiler.</p>
<p>
</p>
<h2><a name="using_large_files_with_perl_on_hpux">Using Large Files with Perl on HP-UX</a></h2>
<p>Beginning with HP-UX version 10.20, files larger than 2GB (2^31 bytes)
may be created and manipulated.  Three separate methods of doing this
are available.  Of these methods, the best method for Perl is to compile
using the -Duselargefiles flag to Configure.  This causes Perl to be
compiled using structures and functions in which these are 64 bits wide,
rather than 32 bits wide.  (Note that this will only work with HP's ANSI
C compiler.  If you want to compile Perl using gcc, you will have to get
a version of the compiler that supports 64-bit operations. See above for
where to find it.)</p>
<p>There are some drawbacks to this approach.  One is that any extension
which calls any file-manipulating C function will need to be recompiled
(just follow the usual &quot;perl Makefile.PL; make; make test; make install&quot;
procedure).</p>
<p><table cellspacing="0" cellpadding="0"><tr><td>The list of functions that will need to recompiled is: