From: John David Anglin Date: Tue, 6 Apr 2004 16:46:27 +0000 (+0000) Subject: * doc/install.texi: Update HP-UX 11 installation procedure. X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=c512449722068d554e172a341fd945284c1cf952;p=gcc.git * doc/install.texi: Update HP-UX 11 installation procedure. From-SVN: r80457 --- diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 5bf83b553fb..567864e851c 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,7 @@ +2004-04-06 John David Anglin + + * doc/install.texi: Update HP-UX 11 installation procedure. + 2004-04-06 Paul Brook * doc/sourcebuild.texi: Remove obsolete contraint on testcases. diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi index 3483acea29c..96ee1850566 100644 --- a/gcc/doc/install.texi +++ b/gcc/doc/install.texi @@ -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. -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. +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. -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. +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. -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: +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@. -@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 +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}. -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. - -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. +It is best to explicitly configure the @samp{hppa64-hp-hpux11*} target +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. + +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. + +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}. + +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 -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.