Skip to content

R
riscv-gcc-1
Commit c5124497 by John David Anglin Committed by John David Anglin
Options

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

From-SVN: r80457
parent 5f3b79c5
Showing with 104 additions and 61 deletions
gcc/ChangeLog
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> 2004-04-06 Paul Brook <paul@codesourcery.com>
* doc/sourcebuild.texi: Remove obsolete contraint on testcases. * doc/sourcebuild.texi: Remove obsolete contraint on testcases.
......
gcc/doc/install.texi
...@@ -2590,9 +2590,8 @@ use GAS and GDB and configure GCC with the ...@@ -2590,9 +2590,8 @@ use GAS and GDB and configure GCC with the
@option{--with-as=@dots{}} options. @option{--with-as=@dots{}} options.
If you wish to use the pa-risc 2.0 architecture support with a 32-bit 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, runtime, you must use either the HP assembler, or gas/binutils 2.11
or a recent or newer.
@uref{ftp://sources.redhat.com/pub/binutils/snapshots,,snapshot of gas}.
There are two default scheduling models for instructions. These are There are two default scheduling models for instructions. These are
PROCESSOR_7100LC and PROCESSOR_8000. They are selected from the pa-risc PROCESSOR_7100LC and PROCESSOR_8000. They are selected from the pa-risc
...@@ -2643,59 +2642,105 @@ the failure from @samp{make bootstrap}. ...@@ -2643,59 +2642,105 @@ the failure from @samp{make bootstrap}.
@end html @end html
@heading @anchor{hppa*-hp-hpux11}hppa*-hp-hpux11 @heading @anchor{hppa*-hp-hpux11}hppa*-hp-hpux11
GCC 3.0 and up support HP-UX 11. On 64-bit capable systems, there GCC 3.0 and up support HP-UX 11. GCC 2.95.x is not supported and cannot
are two distinct ports. The @samp{hppa2.0w-hp-hpux11*} port generates be used to compile GCC 3.0 and up.
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.
It is best to explicitly configure the @samp{hppa64-hp-hpux11*} target Refer to @uref{binaries.html,,binaries} for information about obtaining
with the @option{--with-ld=@dots{}} option. We support both the HP precompiled GCC binaries for HP-UX. Precompiled binaries must be obtained
and GNU linkers for this target. The two linkers require different to build the Ada language as it can't be bootstrapped using C. Ada is
link commands. Thus, it's not possible to switch linkers during a only available for the 32-bit PA-RISC runtime. The libffi and libjava
GCC build. This has been been reported to occur in a unified build haven't been ported to HP-UX and don't build.
of binutils and GCC.
GCC 2.95.x is not supported under HP-UX 11 and cannot be used to It is possible to build GCC 3.3 starting with the bundled HP compiler,
compile GCC 3.0 and up. Refer to @uref{binaries.html,,binaries} for but the process requires several steps. GCC 3.3 can then be used to
information about obtaining precompiled GCC binaries for HP-UX. 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.
You must use GNU binutils 2.11 or above with the 32-bit port. Thread Starting with GCC 3.4 an ISO C compiler is required to bootstrap. The
support is not currently implemented, so @option{--enable-threads} does bundled compiler supports only traditional C; you will need either HP's
not work. See: unbundled compiler, or a binary distribution of GCC@.
@itemize There are several possible approaches to building the distribution.
@item @uref{http://gcc.gnu.org/ml/gcc-prs/2002-01/msg00551.html} Binutils can be built first using the HP tools. Then, the GCC
@item @uref{http://gcc.gnu.org/ml/gcc-bugs/2002-01/msg00663.html} distribution can be built. The second approach is to build GCC
@end itemize 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}.
GCC 3.3 and later support weak symbols on the 32-bit port using SOM It is best to explicitly configure the @samp{hppa64-hp-hpux11*} target
secondary definition symbols. This feature is not enabled for earlier with the @option{--with-ld=@dots{}} option. This overrides the standard
versions of HP-UX since there have been bugs in the linker support for search for ld. The two linkers supported on this target require different
secondary symbols. The HP linker patches @code{PHSS_26559} and commands. The default linker is determined during configuration. As a
@code{PHSS_24304} for HP-UX 11.00 and 11.11, respectively, correct the result, it's not possible to switch linkers in the middle of a GCC build.
problem of linker core dumps creating C++ libraries. Earlier patches This has been been reported to sometimes occur in unified builds of
may work but they have not been tested. binutils and GCC.
GCC 3.3 nows uses the ELF DT_INIT_ARRAY and DT_FINI_ARRAY capability With GCC 3.0 through 3.2, you must use binutils 2.11 or above. As of
to run initializers and finalizers on the 64-bit port. The feature GCC 3.3, binutils 2.14 or later is required.
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 Although the HP assembler can be used for an initial build, it shouldn't
and .fini sections. The 32-bit port uses the linker @option{+init} be used with any languages other than C and perhaps Fortran due to its
and @option{+fini} options. As with the support for secondary symbols, many limitations. For example, it does not support weak symbols or alias
there have been bugs in the order in which these options are executed definitions. As a result, explicit template instantiations are required
by the HP linker. So, again a recent linker patch is recommended. 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 has many limitations and is not recommended for either the HP assembler. Finally, @samp{make bootstrap} fails in the final
the 32 or 64-bit ports. For example, it does not support weak symbols comparison of object modules due to the time stamps that it inserts into
or alias definitions. As a result, explicit template instantiations the modules. The bootstrap can be continued from this point with
are required when using C++. This will make it difficult if not @samp{make all}.
impossible to build many C++ applications. You also can't generate
debugging information when using the HP assembler with GCC. 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.
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 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 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
...@@ -2717,16 +2762,10 @@ with @option{-static}. It doesn't provide stubs for internal ...@@ -2717,16 +2762,10 @@ with @option{-static}. It doesn't provide stubs for internal
calls to global functions in shared libraries, so these calls calls to global functions in shared libraries, so these calls
can't be overloaded. can't be overloaded.
There are several possible approaches to building the distribution. Thread support is not implemented in GCC 3.0 through 3.2, so the
Binutils can be built first using the HP tools. Then, the GCC @option{--enable-threads} configure option does not work. In 3.3
distribution can be built. The second approach is to build GCC and later, POSIX threads are supported. The optional DCE thread
first using the HP tools, then build binutils, then rebuild GCC. library is not supported.
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@.
This port still is undergoing significant development. This port still is undergoing significant development.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment