OpenE2K
/
gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

* doc/install.texi: Update HP-UX 11 installation procedure. 

From-SVN: r80457
This commit is contained in:
John David Anglin 2004-04-06 16:46:27 +00:00 committed by John David Anglin
parent 5f3b79c570
commit c512449722
2 changed files with 103 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
gcc/ChangeLog
View File

@ -1,3 +1,7 @@
2004-04-06 John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
* doc/install.texi: Update HP-UX 11 installation procedure.
2004-04-06 Paul Brook <paul@codesourcery.com>
* doc/sourcebuild.texi: Remove obsolete contraint on testcases.

159
gcc/doc/install.texi
View File

@ -2590,9 +2590,8 @@ use GAS and GDB and configure GCC with the
@option{--with-as=@dots{}} options.
If you wish to use the pa-risc 2.0 architecture support with a 32-bit
runtime, you must use either the HP assembler, gas/binutils 2.11 or newer,
or a recent
@uref{ftp://sources.redhat.com/pub/binutils/snapshots,,snapshot of gas}.
runtime, you must use either the HP assembler, or gas/binutils 2.11
or newer.
There are two default scheduling models for instructions. These are
PROCESSOR_7100LC and PROCESSOR_8000. They are selected from the pa-risc
@ -2643,62 +2642,108 @@ the failure from @samp{make bootstrap}.
@end html
@heading @anchor{hppa*-hp-hpux11}hppa*-hp-hpux11
GCC 3.0 and up support HP-UX 11. On 64-bit capable systems, there
are two distinct ports. The @samp{hppa2.0w-hp-hpux11*} port generates
code for the 32-bit pa-risc runtime architecture. It uses the HP
linker. The @samp{hppa64-hp-hpux11*} port generates 64-bit code for the
pa-risc 2.0 architecture. The script config.guess now selects the port
type based on the type compiler detected during configuration. You must
set your @env{PATH} or define @env{CC} so that configure finds an appropriate
compiler for the initial bootstrap. Different prefixes must be used if
both ports are to be installed on the same system.
GCC 3.0 and up support HP-UX 11. GCC 2.95.x is not supported and cannot
be used to compile GCC 3.0 and up.
Refer to @uref{binaries.html,,binaries} for information about obtaining
precompiled GCC binaries for HP-UX. Precompiled binaries must be obtained
to build the Ada language as it can't be bootstrapped using C. Ada is
only available for the 32-bit PA-RISC runtime. The libffi and libjava
haven't been ported to HP-UX and don't build.
It is possible to build GCC 3.3 starting with the bundled HP compiler,
but the process requires several steps. GCC 3.3 can then be used to
build later versions. The fastjar program contains ISO C code and
can't be built with the HP bundled compiler. This problem can be
avoided by not building the Java language. For example, use the
@option{--enable-languages="c,c++,f77,objc"} option in your configure
command.
Starting with GCC 3.4 an ISO C compiler is required to bootstrap. The
bundled compiler supports only traditional C; you will need either HP's
unbundled compiler, or a binary distribution of GCC@.
There are several possible approaches to building the distribution.
Binutils can be built first using the HP tools. Then, the GCC
distribution can be built. The second approach is to build GCC
first using the HP tools, then build binutils, then rebuild GCC.
There have been problems with various binary distributions, so it
is best not to start from a binary distribution.
On 64-bit capable systems, there are two distinct targets. Different
installation prefixes must be used if both are to be installed on
the same system. The @samp{hppa[1-2]*-hp-hpux11*} target generates code
for the 32-bit PA-RISC runtime architecture and uses the HP linker.
The @samp{hppa64-hp-hpux11*} target generates 64-bit code for the
PA-RISC 2.0 architecture. The HP and GNU linkers are both supported
for this target.
The script config.guess now selects the target type based on the compiler
detected during configuration. You must define @env{PATH} or @env{CC} so
that configure finds an appropriate compiler for the initial bootstrap.
When @env{CC} is used, the definition should contain the options that are
needed whenever @env{CC} is used.
Specifically, options that determine the runtime architecture must be
in @env{CC} to correctly select the target for the build. It is also
convenient to place many other compiler options in @env{CC}. For example,
@env{CC="cc -Ac +DA2.0W -Wp,-H16376 -D_CLASSIC_TYPES -D_HPUX_SOURCE"}
can be used to bootstrap the GCC 3.3 branch with the HP compiler in
64-bit K&R/bundled mode. The @option{+DA2.0W} option will result in
the automatic selection of the @samp{hppa64-hp-hpux11*} target. The
macro definition table of cpp needs to be increased for a successful
build with the HP compiler. _CLASSIC_TYPES and _HPUX_SOURCE need to
be defined when building with the bundled compiler, or when using the
@option{-Ac} option. These defines aren't necessary with @option{-Ae}.
It is best to explicitly configure the @samp{hppa64-hp-hpux11*} target
with the @option{--with-ld=@dots{}} option. We support both the HP
and GNU linkers for this target. The two linkers require different
link commands. Thus, it's not possible to switch linkers during a
GCC build. This has been been reported to occur in a unified build
of binutils and GCC.
with the @option{--with-ld=@dots{}} option. This overrides the standard
search for ld. The two linkers supported on this target require different
commands. The default linker is determined during configuration. As a
result, it's not possible to switch linkers in the middle of a GCC build.
This has been been reported to sometimes occur in unified builds of
binutils and GCC.
GCC 2.95.x is not supported under HP-UX 11 and cannot be used to
compile GCC 3.0 and up. Refer to @uref{binaries.html,,binaries} for
information about obtaining precompiled GCC binaries for HP-UX.
With GCC 3.0 through 3.2, you must use binutils 2.11 or above. As of
GCC 3.3, binutils 2.14 or later is required.
You must use GNU binutils 2.11 or above with the 32-bit port. Thread
support is not currently implemented, so @option{--enable-threads} does
not work. See:
Although the HP assembler can be used for an initial build, it shouldn't
be used with any languages other than C and perhaps Fortran due to its
many limitations. For example, it does not support weak symbols or alias
definitions. As a result, explicit template instantiations are required
when using C++. This makes it difficult if not impossible to build many
C++ applications. You can't generate debugging information when using
the HP assembler. Finally, @samp{make bootstrap} fails in the final
comparison of object modules due to the time stamps that it inserts into
the modules. The bootstrap can be continued from this point with
@samp{make all}.
@itemize
@item @uref{http://gcc.gnu.org/ml/gcc-prs/2002-01/msg00551.html}
@item @uref{http://gcc.gnu.org/ml/gcc-bugs/2002-01/msg00663.html}
@end itemize
A recent linker patch must be installed for the correct operation of
GCC 3.3 and later. @code{PHSS_26559} and @code{PHSS_24304} are the
oldest linker patches that are known to work. They are for HP-UX
11.00 and 11.11, respectively. @code{PHSS_24303}, the companion to
@code{PHSS_24304}, might be usable but it hasn't been tested. These
patches have been superseded. Consult the HP patch database to obtain
the currently recommended linker patch for your system.
GCC 3.3 and later support weak symbols on the 32-bit port using SOM
secondary definition symbols. This feature is not enabled for earlier
versions of HP-UX since there have been bugs in the linker support for
secondary symbols. The HP linker patches @code{PHSS_26559} and
@code{PHSS_24304} for HP-UX 11.00 and 11.11, respectively, correct the
problem of linker core dumps creating C++ libraries. Earlier patches
may work but they have not been tested.
The patches are necessary for the support of weak symbols on the
32-bit port, and for the running of initializers and finalizers. Weak
symbols are implemented using SOM secondary definition symbols. Prior
to HP-UX 11, there are bugs in the linker support for secondary symbols.
The patches correct a problem of linker core dumps creating shared
libraries containing secondary symbols, as well as various other
linking issues involving secondary symbols.
GCC 3.3 nows uses the ELF DT_INIT_ARRAY and DT_FINI_ARRAY capability
to run initializers and finalizers on the 64-bit port. The feature
requires CVS binutils as of January 2, 2003, or a subsequent release
to correct a problem arising from HP's non-standard use of the .init
and .fini sections. The 32-bit port uses the linker @option{+init}
and @option{+fini} options. As with the support for secondary symbols,
there have been bugs in the order in which these options are executed
by the HP linker. So, again a recent linker patch is recommended.
The HP assembler has many limitations and is not recommended for either
the 32 or 64-bit ports. For example, it does not support weak symbols
or alias definitions. As a result, explicit template instantiations
are required when using C++. This will make it difficult if not
impossible to build many C++ applications. You also can't generate
debugging information when using the HP assembler with GCC.
GCC 3.3 uses the ELF DT_INIT_ARRAY and DT_FINI_ARRAY capabilities to
run initializers and finalizers on the 64-bit port. The 32-bit port
uses the linker @option{+init} and @option{+fini} options for the same
purpose. The patches correct various problems with the +init/+fini
options, including program core dumps. Binutils 2.14 corrects a
problem on the 64-bit port resulting from HP's non-standard use of
the .init and .fini sections for array initializers and finalizers.
There are a number of issues to consider in selecting which linker to
use with the 64-bit port. The GNU 64-bit linker can only create dynamic
use with the 64-bit port. The GNU 64-bit linker can only create dynamic
binaries. The @option{-static} option causes linking with archive
libraries but doesn't produce a truly static binary. Dynamic binaries
still require final binding by the dynamic loader to resolve a set of
@ -2717,16 +2762,10 @@ with @option{-static}. It doesn't provide stubs for internal
calls to global functions in shared libraries, so these calls
can't be overloaded.
There are several possible approaches to building the distribution.
Binutils can be built first using the HP tools. Then, the GCC
distribution can be built. The second approach is to build GCC
first using the HP tools, then build binutils, then rebuild GCC.
There have been problems with various binary distributions, so
it is best not to start from a binary distribution.
Starting with GCC 3.4 an ISO C compiler is required to bootstrap.
The bundled compiler supports only traditional C; you will need
either HP's unbundled compiler, or a binary distribution of GCC@.
Thread support is not implemented in GCC 3.0 through 3.2, so the
@option{--enable-threads} configure option does not work. In 3.3
and later, POSIX threads are supported. The optional DCE thread
library is not supported.
This port still is undergoing significant development.