* Re: gcc-64 on HP-UX 11.00
[not found] ` <200204112027.g3BKR6DK001129@hiauly1.hia.nrc.ca>
@ 2002-04-12 3:19 ` H.Merijn Brand
2002-04-12 4:39 ` H.Merijn Brand
0 siblings, 1 reply; 32+ messages in thread
From: H.Merijn Brand @ 2002-04-12 3:19 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc
On Thu 11 Apr 2002 22:27, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > > The results from previous executions of configure are kept in
> > > config.cache. So, at a minimum, all config.cache files need to be
> >
> > In which directory? In the src directory? Whoa, then I have to change my
> > scripts.
> >
> > > removed before rerunning configure.
>
> They are all in the build directory.
>
> >
> > Alternate solution. Temporary rename all GNU ld's so it cannot find them.
> > Would that help? or will it stop stage1/stage2?
>
> You want to use HP ld for the entire first build. If
> "--with-ld=/usr/ccs/bin/ld" is wrong, configure falls back to searching
> for an appropriate linker. This could have been how you got the gnu
> linker again. You should see the result of the selection in the
> configure output. You can also see the DEFAULT_LINKER selected in
> gcc/config.status. Renaming should work but it shouldn't be necessary.
a5:/pro/3gl/GNU/gcc 127 > cat Conf-64a
#!/usr/bin/sh
export LD_PXDB=/usr/bin/true
export CONFIG_SITE=
export CC="cc -Ae +DA2.0W"
export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/opt/imake/bin
rm -rf obj
mkdir obj
cd obj
../src/configure \
--enable-languages=c \
--prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 \
--with-gnu-as --with-as=/usr/local/pa20_64/bin/as \
--with-ld=/usr/ccs/bin/ld \
--disable-shared \
--disable-nls \
--host=hppa64-hp-hpux11.00
echo ""
echo "Now start 'Build-64'"
a5:/pro/3gl/GNU/gcc 128 > Conf-64a
*** This configuration is not supported in the following subdirectories:
target-libffi target-boehm-gc target-zlib target-libjava target-libchill target-libstdc++-v3 target-libf2c zlib fastjar target-libobjc
(Any other directories should still work fine.)
Created "Makefile" in /pro/3gl/GNU/gcc/obj using "mh-frag"
ld: (Warning) Can't exec pxdb using path: /usr/bin/true
Configuring libiberty...
creating cache ../config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking for makeinfo... makeinfo
configure: warning:
*** Makeinfo is too old. Info documentation will not be built.
checking for perl... perl
checking host system type... hppa64-hp-hpux11.00
checking build system type... hppa64-hp-hpux11.00
checking for ar... ar
checking for ranlib... ranlib
checking for gcc... cc -Ae +DA2.0W
checking whether we are using GNU C... no
checking for POSIXized ISC... no
checking for working const... yes
checking for inline... inline
checking for a BSD compatible install... /opt/imake/bin/install -c
checking how to run the C preprocessor... cc -Ae +DA2.0W -E
checking for sys/file.h... yes
checking for sys/param.h... yes
checking for limits.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for unistd.h... yes
checking for strings.h... yes
checking for sys/time.h... yes
checking for time.h... yes
checking for sys/resource.h... yes
checking for sys/stat.h... yes
checking for sys/mman.h... yes
checking for fcntl.h... yes
checking for alloca.h... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether errno must be declared... no
checking for ANSI C header files... yes
checking for uintptr_t... yes
checking whether the C compiler (cc -Ae +DA2.0W -g ) works... yes
checking whether the C compiler (cc -Ae +DA2.0W -g ) is a cross-compiler... no
checking for asprintf... no
checking for atexit... yes
checking for basename... yes
checking for bcmp... yes
checking for bcopy... yes
checking for bsearch... yes
checking for bzero... yes
checking for calloc... yes
checking for clock... yes
checking for ffs... yes
checking for getcwd... yes
checking for getpagesize... yes
checking for index... yes
checking for insque... yes
checking for memchr... yes
checking for memcmp... yes
checking for memcpy... yes
checking for memmove... yes
checking for memset... yes
checking for mkstemps... no
checking for putenv... yes
checking for random... yes
checking for rename... yes
checking for rindex... yes
checking for setenv... no
checking for sigsetmask... yes
checking for strcasecmp... yes
checking for strchr... yes
checking for strdup... yes
checking for strncasecmp... yes
checking for strrchr... yes
checking for strstr... yes
checking for strtod... yes
checking for strtol... yes
checking for strtoul... yes
checking for tmpnam... yes
checking for vasprintf... no
checking for vfprintf... yes
checking for vprintf... yes
checking for vsprintf... yes
checking for waitpid... yes
checking whether alloca needs Cray hooks... no
checking stack direction for C alloca... 1
checking for pid_t... yes
checking for vfork.h... no
checking for working vfork... yes
checking for _doprnt... yes
checking for sys_errlist... yes
checking for sys_nerr... yes
checking for sys_siglist... no
checking for getrusage... yes
checking for on_exit... no
checking for psignal... no
checking for strerror... yes
checking for strsignal... no
checking for sysconf... yes
checking for times... yes
checking for sbrk... yes
checking for gettimeofday... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking for sys/types.h... yes
checking for getpagesize... (cached) yes
checking for working mmap... no
checking for working strncmp... yes
updating cache ../config.cache
creating ./config.status
creating Makefile
creating testsuite/Makefile
creating config.h
Configuring gcc...
loading cache ../config.cache
checking LIBRARY_PATH variable... ok
checking GCC_EXEC_PREFIX variable... ok
checking host system type... hppa64-hp-hpux11.00
checking target system type... hppa64-hp-hpux11.00
checking build system type... hppa64-hp-hpux11.00
checking for gcc... (cached) cc -Ae +DA2.0W
checking whether the C compiler (cc -Ae +DA2.0W -g ) works... yes
checking whether the C compiler (cc -Ae +DA2.0W -g ) is a cross-compiler... no
checking whether we are using GNU C... (cached) no
checking whether cc -Ae +DA2.0W accepts -g... yes
checking whether cc -Ae +DA2.0W and cc understand -c and -o together... yes
checking whether cc -Ae +DA2.0W accepts -Wno-long-long... yes
checking how to run the C preprocessor... (cached) cc -Ae +DA2.0W -E
checking for inline... (cached) inline
checking for volatile... yes
checking for long double... yes
checking for long long int... yes
checking for __int64... no
checking for built-in _Bool... yes
checking size of short... 2
checking size of int... 4
checking size of long... 8
checking size of long long... 8
checking execution character set... ASCII
checking whether make sets ${MAKE}... yes
checking whether a default assembler was specified... yes (/usr/local/pa20_64/bin/as - GNU as)
checking whether a default linker was specified... yes (/usr/ccs/bin/ld)
checking for GNU C library... no
checking for gawk... gawk
checking whether ln works... yes
checking whether ln -s works... yes
checking for ranlib... (cached) ranlib
checking for a BSD compatible install... (cached) /opt/imake/bin/install -c
checking for ANSI C header files... (cached) yes
checking whether time.h and sys/time.h may both be included... (cached) yes
checking for working stdbool.h... yes
checking whether string.h and strings.h may both be included... yes
checking for sys/wait.h that is POSIX.1 compatible... (cached) yes
checking for limits.h... (cached) yes
checking for stddef.h... yes
checking for string.h... (cached) yes
checking for strings.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for time.h... (cached) yes
checking for fcntl.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/file.h... (cached) yes
checking for sys/time.h... (cached) yes
checking for sys/resource.h... (cached) yes
checking for sys/param.h... (cached) yes
checking for sys/times.h... yes
checking for sys/stat.h... (cached) yes
checking for direct.h... no
checking for malloc.h... yes
checking for langinfo.h... yes
checking for thread.h... no
checking for pthread.h... yes
checking for CHAR_BIT... yes
checking byte ordering... big-endian
checking floating point format... IEEE (big-endian)
checking for gnatbind... no
checking for compiler driver that understands Ada... cc
checking for mktemp... yes
checking for makeinfo... (cached) makeinfo
checking for modern makeinfo... no
configure: warning:
*** Makeinfo is missing or too old.
*** Info documentation will not be built.
checking for recent Pod::Man... yes
checking for flex... flex
checking for bison... bison
checking for collect2 libraries... none required
checking for library containing exc_resume... no
checking for preprocessor stringizing operator... yes
checking for inttypes.h... yes
checking for times... (cached) yes
checking for clock... (cached) yes
checking for dup2... yes
checking for kill... yes
checking for getrlimit... yes
checking for setrlimit... yes
checking for atoll... no
checking for atoq... no
checking for sysconf... (cached) yes
checking for strsignal... (cached) no
checking for putc_unlocked... yes
checking for fputc_unlocked... no
checking for fputs_unlocked... no
checking for fwrite_unlocked... no
checking for fprintf_unlocked... no
checking for getrusage... (cached) yes
checking for nl_langinfo... yes
checking for lstat... yes
checking for ssize_t... yes
checking for uid_t in sys/types.h... yes
checking type of array argument to getgroups... gid_t
checking whether the printf functions support %p... yes
checking for pid_t... (cached) yes
checking for vfork.h... (cached) no
checking for working vfork... (cached) yes
checking for getpagesize... (cached) yes
checking for working mmap from /dev/zero... no
checking for working mmap with MAP_ANON(YMOUS)... yes
checking for working mmap of a file... yes
checking for iconv... yes
checking for iconv declaration...
extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
checking whether getenv is declared... yes
checking whether atol is declared... yes
checking whether sbrk is declared... yes
checking whether abort is declared... yes
checking whether atof is declared... yes
checking whether getcwd is declared... yes
checking whether getwd is declared... yes
checking whether strsignal is declared... yes
checking whether putc_unlocked is declared... no
checking whether fputs_unlocked is declared... no
checking whether fwrite_unlocked is declared... no
checking whether fprintf_unlocked is declared... no
checking whether strstr is declared... yes
checking whether errno is declared... yes
checking whether malloc is declared... yes
checking whether realloc is declared... yes
checking whether calloc is declared... yes
checking whether free is declared... yes
checking whether basename is declared... no
checking whether getopt is declared... yes
checking whether clock is declared... yes
checking whether getrlimit is declared... yes
checking whether setrlimit is declared... yes
checking whether getrusage is declared... yes
checking whether times is declared... yes
checking for struct tms... yes
checking for clock_t... yes
checking if mkdir takes one argument... no
Using `../../src/gcc/config/pa/pa.c' for machine-specific logic.
Using `../../src/gcc/config/pa/pa.md' as machine description file.
Using the following target machine macro files:
../../src/gcc/config/pa/pa64-start.h
../../src/gcc/config/pa/pa.h
../../src/gcc/config/pa/pa64-regs.h
../../src/gcc/config/pa/long_double.h
../../src/gcc/config/pa/elf.h
../../src/gcc/config/pa/pa-hpux.h
../../src/gcc/config/pa/pa-hpux11.h
../../src/gcc/config/pa/pa-64.h
../../src/gcc/config/pa/pa64-hpux.h
checking for library containing strerror... none required
checking for working const... (cached) yes
checking for off_t... yes
checking for size_t... yes
checking for working alloca.h... (cached) yes
checking for alloca... yes
checking whether we are using the GNU C Library 2.1 or newer... no
checking for argz.h... no
checking for limits.h... (cached) yes
checking for locale.h... yes
checking for nl_types.h... yes
checking for malloc.h... (cached) yes
checking for stddef.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... (cached) yes
checking for feof_unlocked... no
checking for fgets_unlocked... no
checking for getcwd... (cached) yes
checking for getegid... yes
checking for geteuid... yes
checking for getgid... yes
checking for getuid... yes
checking for mempcpy... no
checking for munmap... yes
checking for putenv... (cached) yes
checking for setenv... (cached) no
checking for setlocale... yes
checking for stpcpy... no
checking for strchr... (cached) yes
checking for strcasecmp... (cached) yes
checking for strdup... (cached) yes
checking for strtoul... (cached) yes
checking for tsearch... yes
checking for __argz_count... no
checking for __argz_stringify... no
checking for __argz_next... no
checking for iconv... (cached) yes
checking for iconv declaration... (cached)
extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
checking for nl_langinfo and CODESET... yes
checking for LC_MESSAGES... yes
checking whether NLS is requested... no
checking for bison... bison
checking version of bison... 1.34, ok
checking what assembler to use... /usr/local/pa20_64/bin/as
checking what linker to use... /usr/ccs/bin/ld
checking what nm to use... nm
checking what objdump to use... objdump
checking assembler alignment features... .p2align including maximum skip
checking assembler subsection support... working .subsection -1
checking assembler weak support... yes
checking assembler hidden support... yes
checking assembler leb128 support... yes
checking assembler eh_frame optimization... yes
checking assembler section merging support... no
checking assembler dwarf2 debug_line support... no
checking assembler --gdwarf2 support... no
checking assembler --gstabs support... no
checking linker PT_GNU_EH_FRAME support... no
Using ggc-page for garbage collection.
checking whether to enable maintainer-specific portions of Makefiles... no
Links are now set up to build a native compiler for hppa64-hp-hpux11.00
updating cache ../config.cache
creating ./config.status
creating Makefile
creating intl/Makefile
creating fixinc/Makefile
creating gccbug
creating mklibgcc
creating auto-host.h
Now start 'Build-64'
a5:/pro/3gl/GNU/gcc 129 > grep DEFAULT_LINKER obj/gcc/config.status
${ac_dA}DEFAULT_LINKER${ac_dB}DEFAULT_LINKER${ac_dC}"/usr/ccs/bin/ld"${ac_dD}
${ac_uA}DEFAULT_LINKER${ac_uB}DEFAULT_LINKER${ac_uC}"/usr/ccs/bin/ld"${ac_uD}
${ac_eA}DEFAULT_LINKER${ac_eB}DEFAULT_LINKER${ac_eC}"/usr/ccs/bin/ld"${ac_eD}
a5:/pro/3gl/GNU/gcc 130 > cat Build-64a
#!/usr/bin/sh
export LD_PXDB=/usr/bin/true
export CONFIG_SITE=
export CC="cc -Ae +DA2.0W"
export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/opt/imake/bin
cd obj
make bootstrap-lean
a5:/pro/3gl/GNU/gcc 131 > Build-64a
:
:
make[3]: Entering directory `/pro/3gl/GNU/gcc/obj/gcc'
for d in libgcc; do \
if [ -d $d ]; then true; else /bin/sh ../../src/gcc/mkinstalldirs $d; fi; \
done
if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi
make[3]: Leaving directory `/pro/3gl/GNU/gcc/obj/gcc'
make[2]: Leaving directory `/pro/3gl/GNU/gcc/obj/gcc'
make[1]: Leaving directory `/pro/3gl/GNU/gcc/obj'
a5:/pro/3gl/GNU/gcc 132 > banner ':-)'
##
## #
## #
##### #
#
## #
## ##
a5:/pro/3gl/GNU/gcc 133 > cat Install-64a
#!/usr/bin/sh
export LD_PXDB=/usr/bin/true
export CONFIG_SITE=
export CC="cc -Ae +DA2.0W"
export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/opt/imake/bin
cd obj
make install
a5:/pro/3gl/GNU/gcc 134 > Install-64a
:
a5:/pro/3gl/GNU/gcc 135 > file /wrk/pa20_64/bin/gcc
/wrk/pa20_64/bin/gcc: ELF-64 executable object file - PA-RISC 2.0 (LP64)
a5:/pro/3gl/GNU/gcc 136 > ll /wrk/pa20_64/bin/gcc
558 -rwxr-xr-x 2 merijn softwr 606200 Apr 12 11:34 /wrk/pa20_64/bin/gcc
a5:/pro/3gl/GNU/gcc 137 > /wrk/pa20_64/bin/gcc --version
gcc (GCC) 3.1 20020408 (prerelease)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
a5:/pro/3gl/GNU/gcc 138 >
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-12 3:19 ` gcc-64 on HP-UX 11.00 H.Merijn Brand
@ 2002-04-12 4:39 ` H.Merijn Brand
2002-04-12 5:08 ` H.Merijn Brand
` (2 more replies)
0 siblings, 3 replies; 32+ messages in thread
From: H.Merijn Brand @ 2002-04-12 4:39 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc
On Fri 12 Apr 2002 11:45, H.Merijn Brand <h.m.brand@hccnet.nl> wrote:
> On Thu 11 Apr 2002 22:27, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > > > The results from previous executions of configure are kept in
> > > > config.cache. So, at a minimum, all config.cache files need to be
After that I used the newly installed gcc to build it again:
--8<--- Conf-gcc64
#!/usr/bin/sh
export CONFIG_SITE=
export CC="gcc64 -mpa-risc-2-0"
export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/opt/imake/bin
rm -rf obj
mkdir obj
cd obj
../src/configure \
--enable-languages=c \
--prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 \
--with-gnu-as --with-as=/usr/local/pa20_64/bin/as \
--with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld \
--disable-shared \
--disable-nls \
--host=hppa64-hp-hpux11.00
-->8---
and
--8<--- Build-gcc64
#!/usr/bin/sh
export CONFIG_SITE=
export CC="gcc64 -mpa-risc-2-0"
export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/opt/imake/bin
cd obj
make bootstrap-lean
-->8---
and
--8<--- Install-gcc64
#!/usr/bin/sh
export CONFIG_SITE=
export CC="gcc64 -mpa-risc-2-0"
export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/opt/imake/bin
cd obj
make install
-->8---
And then I tried to use it to build bleadperl. I know it's pushing the limits,
but somehow I just /had to/ try :))
CCCMD = gcc64 -DPERL_CORE -c -mpa-risc-2-0 -DDEBUGGING -D_HPUX_SOURCE -DDEBUGGING -fno-strict-aliasing -I/usr/local/pa20_64/include -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O -Wall
cc1: warning: changing search order for system directory "/usr/local/pa20_64/include"
cc1: warning: as it has already been specified as a non-system directory
cc1: warning: changing search order for system directory "/usr/local/pa20_64/include"
cc1: warning: as it has already been specified as a non-system directory
gv.c: In function `Perl_gv_init':
gv.c:126: warning: unused variable `Perl___notused'
gv.c:130: warning: unused variable `Perl___notused'
gv.c: In function `Perl_gv_autoload4':
gv.c:521: warning: unused variable `Perl___notused'
gv.c:528: warning: unused variable `Perl___notused'
gv.c: In function `S_require_errno':
gv.c:551: warning: unused variable `Perl___notused'
gv.c:555: warning: unused variable `Perl___notused'
gv.c: In function `Perl_amagic_call':
gv.c:1707: warning: unused variable `Perl___notused'
gv.c:1727: warning: unused variable `Perl___notused'
gv.c:1772: output_operand: invalid expression as operand
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make: *** [gv.o] Error 1
a5:/pro/3gl/CPAN/perl-current 125 >
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-12 4:39 ` H.Merijn Brand
@ 2002-04-12 5:08 ` H.Merijn Brand
2002-04-12 9:34 ` John David Anglin
2002-04-13 10:40 ` John David Anglin
2 siblings, 0 replies; 32+ messages in thread
From: H.Merijn Brand @ 2002-04-12 5:08 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc
[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]
On Fri 12 Apr 2002 13:32, H.Merijn Brand <h.m.brand@hccnet.nl> wrote:
> On Fri 12 Apr 2002 11:45, H.Merijn Brand <h.m.brand@hccnet.nl> wrote:
> > On Thu 11 Apr 2002 22:27, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > > > > The results from previous executions of configure are kept in
> > > > > config.cache. So, at a minimum, all config.cache files need to be
>
> After that I used the newly installed gcc to build it again:
>
> --8<--- Conf-gcc64
> #!/usr/bin/sh
>
> export CONFIG_SITE=
> export CC="gcc64 -mpa-risc-2-0"
> export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
> export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
> export PATH=$PATH"":/opt/imake/bin
>
> rm -rf obj
> mkdir obj
> cd obj
> ../src/configure \
> --enable-languages=c \
> --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 \
> --with-gnu-as --with-as=/usr/local/pa20_64/bin/as \
> --with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld \
> --disable-shared \
> --disable-nls \
> --host=hppa64-hp-hpux11.00
> -->8---
>
> and
>
> --8<--- Build-gcc64
> #!/usr/bin/sh
>
> export CONFIG_SITE=
> export CC="gcc64 -mpa-risc-2-0"
> export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
> export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
> export PATH=$PATH"":/opt/imake/bin
>
> cd obj
> make bootstrap-lean
> -->8---
>
> and
>
> --8<--- Install-gcc64
> #!/usr/bin/sh
>
> export CONFIG_SITE=
> export CC="gcc64 -mpa-risc-2-0"
> export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
> export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
> export PATH=$PATH"":/opt/imake/bin
>
> cd obj
> make install
> -->8---
And the (cleaned from promped escapes) script log
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
[-- Attachment #2: log2.bz2 --]
[-- Type: application/octet-stream, Size: 20735 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-12 4:39 ` H.Merijn Brand
2002-04-12 5:08 ` H.Merijn Brand
@ 2002-04-12 9:34 ` John David Anglin
2002-04-13 10:40 ` John David Anglin
2 siblings, 0 replies; 32+ messages in thread
From: John David Anglin @ 2002-04-12 9:34 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: gcc
> And then I tried to use it to build bleadperl. I know it's pushing the limits,
> but somehow I just /had to/ try :))
Don't you know that you have to break a compiler in slowly :-)
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-12 4:39 ` H.Merijn Brand
2002-04-12 5:08 ` H.Merijn Brand
2002-04-12 9:34 ` John David Anglin
@ 2002-04-13 10:40 ` John David Anglin
2002-04-15 8:45 ` law
2 siblings, 1 reply; 32+ messages in thread
From: John David Anglin @ 2002-04-13 10:40 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: gcc
> gv.c: In function `Perl_amagic_call':
> gv.c:1707: warning: unused variable `Perl___notused'
> gv.c:1727: warning: unused variable `Perl___notused'
> gv.c:1772: output_operand: invalid expression as operand
I believe that the enclosed patch fixes the above problem. However, it's
not the end of the problems. In my build, miniperl seg faults when it first
runs. Don't know if this is a gcc or perl problem.
The patch has passed bootstrap and regression testing. However, I want
to study the matter further as it possible this can happen on any PA2.0
machine, and not just TARGET_64BIT machines.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
2002-04-13 John David Anglin <dave@hiauly1.hia.nrc.ca>
* pa.md: Add new floating point load pattern.
Index: pa.md
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/pa/pa.md,v
retrieving revision 1.101
diff -u -3 -p -r1.101 pa.md
--- pa.md 4 Feb 2002 21:05:25 -0000 1.101
+++ pa.md 13 Apr 2002 05:00:52 -0000
@@ -3105,9 +3105,9 @@
(define_insn ""
[(set (match_operand:DI 0 "reg_or_nonsymb_mem_operand"
- "=r,r,r,r,r,r,Q,*q,!f,f,*TR")
+ "=r,r,r,r,r,r,Q,*q,!f,f,f,*TR")
(match_operand:DI 1 "move_operand"
- "A,r,J,N,K,RQ,rM,rM,!fM,*RT,f"))]
+ "A,r,J,N,K,RQ,rM,rM,!fM,A,*RT,f"))]
"(register_operand (operands[0], DImode)
|| reg_or_0_operand (operands[1], DImode))
&& ! TARGET_SOFT_FLOAT && TARGET_64BIT"
@@ -3121,11 +3121,12 @@
std%M0 %r1,%0
mtsar %r1
fcpy,dbl %f1,%0
+ fldd%F1 RT'%A1,%0
fldd%F1 %1,%0
fstd%F0 %1,%0"
- [(set_attr "type" "load,move,move,move,shift,load,store,move,fpalu,fpload,fpstore")
+ [(set_attr "type" "load,move,move,move,shift,load,store,move,fpalu,fpload,fpload,fpstore")
(set_attr "pa_combine_type" "addmove")
- (set_attr "length" "4,4,4,4,4,4,4,4,4,4,4")])
+ (set_attr "length" "4,4,4,4,4,4,4,4,4,4,4,4")])
(define_insn ""
[(set (match_operand:DI 0 "reg_or_nonsymb_mem_operand"
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-13 10:40 ` John David Anglin
@ 2002-04-15 8:45 ` law
2002-04-15 9:46 ` John David Anglin
0 siblings, 1 reply; 32+ messages in thread
From: law @ 2002-04-15 8:45 UTC (permalink / raw)
To: John David Anglin; +Cc: H.Merijn Brand, gcc
In message <200204131603.g3DG3qut006131@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
> > gv.c: In function `Perl_amagic_call':
> > gv.c:1707: warning: unused variable `Perl___notused'
> > gv.c:1727: warning: unused variable `Perl___notused'
> > gv.c:1772: output_operand: invalid expression as operand
>
> I believe that the enclosed patch fixes the above problem. However, it's
> not the end of the problems. In my build, miniperl seg faults when it first
> runs. Don't know if this is a gcc or perl problem.
>
> The patch has passed bootstrap and regression testing. However, I want
> to study the matter further as it possible this can happen on any PA2.0
> machine, and not just TARGET_64BIT machines.
Hmm, my question would be why didn't we use a general register as the
destination? I guess it's technically possible to get into the
situation you're trying to fix, but it may be happening due to problems
elsewhere.
jeff
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-15 8:45 ` law
@ 2002-04-15 9:46 ` John David Anglin
2002-04-15 10:05 ` law
0 siblings, 1 reply; 32+ messages in thread
From: John David Anglin @ 2002-04-15 9:46 UTC (permalink / raw)
To: law; +Cc: h.m.brand, gcc
> > The patch has passed bootstrap and regression testing. However, I want
> > to study the matter further as it possible this can happen on any PA2.0
> > machine, and not just TARGET_64BIT machines.
> Hmm, my question would be why didn't we use a general register as the
> destination? I guess it's technically possible to get into the
> situation you're trying to fix, but it may be happening due to problems
> elsewhere.
The error is caused by allowing symbolic LO_SUM addresses for PA2.0
(GO_IF_LEGITIMATE_ADDRESS), the T constraint which accepts LO_SUM
addresses, and an output template that can't print these addresses.
For hppa64, we have
target_cpu_default="(MASK_PA_11|MASK_PA_20|MASK_GAS)"
and for
hppa2*-*-hpux11*
we have
target_cpu_default="MASK_PA_11"
Thus, we don't generate PA2.0 on wide machines in 32bit mode by default.
This explains why the problem hasn't been seen on 32bit machines.
The same error occurs in 32bit mode with these options using gas:
# gcc -O -mpa-risc-2-0 -fPIC -S gv.i
gv.c: In function `Perl_amagic_call':
gv.c:1774: output_operand: invalid expression as operand
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
As far as I can tell, the address form used in the patch is ok
in PA2.0 code and it saves one instruction over forcing the address
to a register. However, we need to fix the 32 bit pattern(s) as
well.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-15 9:46 ` John David Anglin
@ 2002-04-15 10:05 ` law
2002-04-15 11:42 ` John David Anglin
0 siblings, 1 reply; 32+ messages in thread
From: law @ 2002-04-15 10:05 UTC (permalink / raw)
To: John David Anglin; +Cc: h.m.brand, gcc
In message <200204151646.g3FGkEtp008502@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
> > > The patch has passed bootstrap and regression testing. However, I want
> > > to study the matter further as it possible this can happen on any PA2.0
> > > machine, and not just TARGET_64BIT machines.
> > Hmm, my question would be why didn't we use a general register as the
> > destination? I guess it's technically possible to get into the
> > situation you're trying to fix, but it may be happening due to problems
> > elsewhere.
>
> The error is caused by allowing symbolic LO_SUM addresses for PA2.0
> (GO_IF_LEGITIMATE_ADDRESS), the T constraint which accepts LO_SUM
> addresses, and an output template that can't print these addresses.
Yes, I know that.
[ ... ]
> The same error occurs in 32bit mode with these options using gas:
>
> # gcc -O -mpa-risc-2-0 -fPIC -S gv.i
> gv.c: In function `Perl_amagic_call':
> gv.c:1774: output_operand: invalid expression as operand
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
>
> As far as I can tell, the address form used in the patch is ok
> in PA2.0 code and it saves one instruction over forcing the address
> to a register. However, we need to fix the 32 bit pattern(s) as
> well.
This isn't what I'm looking for.
Based on the information I saw in the patch, you're loading something out of
the DLT into a floating point register. That's an exceedingly bad thing to
do, and while I don't doubt it can happen, I'd like to know more about why
it happened. What caused us to do something that dumb.
jeff
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-15 10:05 ` law
@ 2002-04-15 11:42 ` John David Anglin
0 siblings, 0 replies; 32+ messages in thread
From: John David Anglin @ 2002-04-15 11:42 UTC (permalink / raw)
To: law; +Cc: h.m.brand, gcc
> This isn't what I'm looking for.
Thought so but thought I would supply the easy stuff first. My time for
gcc is going to be limited in the next couple of weeks until I clear
up a number of personal matters. Today, is about the last day.
> Based on the information I saw in the patch, you're loading something out of
> the DLT into a floating point register. That's an exceedingly bad thing to
> do, and while I don't doubt it can happen, I'd like to know more about why
> it happened. What caused us to do something that dumb.
The pseudos for PL_sv_yes and PL_sv_no are assigned to floating point
registers in the greg pass. In other identical rtl, the pseudos are allocated
to general registers. The routine has quite a few pseudos (~667).
The following little test program duplicates the code where we assign
to floating point registers but in this case general register end up
being used as expected.
typedef struct sv SV;
extern SV PL_sv_yes;
extern SV PL_sv_no;
struct sv {
void * sv_any;
unsigned int sv_refcnt;
unsigned int sv_flags;
};
SV *
foo (ans)
int ans;
{
return ((ans) ? &PL_sv_yes : &PL_sv_no);
}
This generates code like:
cmpib,= 0,%r26,L$0002
addil LT'PL_sv_no,%r19
addil LT'PL_sv_yes,%r19
bve (%r2)
ldw RT'PL_sv_yes(%r1),%r28
L$0002
bve (%r2)
ldw RT'PL_sv_no(%r1),%r28
However, the code from the actual perl function looks like:
cmpib,= 0,%r3,L$1012
addil LT'PL_sv_no,%r27
addil LT'PL_sv_yes,%r27
b L$1013
fldd RT'PL_sv_yes(%r1),%fr22
L$1012
fldd RT'PL_sv_no(%r1),%fr22
L$1013
fstd %fr22,-272(%r30)
b L$0783
ldd -272(%r30),%r25
[...]
L$1017
copy %r28,%r25
L$0783
copy %r25,%r28
[restore registers and return]
Thus, it is clear that the compiler somehow failed to find that it could use
%r28 instead of %fr22 and %r25. There are probably more paths to the return
but it seems like something is wrong. I guess also the cost to free up
a general register must have been greater than 16 in the perl code.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-16 13:14 ` law
@ 2002-04-16 15:25 ` John David Anglin
0 siblings, 0 replies; 32+ messages in thread
From: John David Anglin @ 2002-04-16 15:25 UTC (permalink / raw)
To: law; +Cc: h.m.brand, gcc
> I don't doubt that it worked in the past. My point is that selecting an
My point in looking at whether it worked in the past was simply to determine
whether this was in fact a regression, and whether a fix could be applied
to the 3.1 branch.
> FP register to hold an address like this is an exceedingly bad thing to
> do. In fact, not assigning the value to a register and instead leaving it
> in memory is actually cheaper than assigning it to an FP register.
I don't quite follow that logic. Two insns are needed to load the
address and the result must end up in a register. You can't load
the address directly to memory. It takes a couple of insns to copy
the result from the FP register to a general register. Generally,
I guess this must be weighed against the cost of freeing up a general
general.
> In fact, from the fragments, it looks like we did something insanely stupid,
> why don't we assign the value to %r28 or %r25?
I agree it seems very dumb. We have the following rtl at the end of
function after lreg:
(insn 3088 3494 3091 (set (reg/i:DI 28 %r28)
(reg/f:DI 66)) 119 {*pa.md:3106} (nil)
(expr_list:REG_DEAD (reg/f:DI 66)
(nil)))
DI 66 is set in multiple places. It seems the compiler doesn't
recognize opportunities to replace DI 66 with DI 28, and so on.
Jeff, I will send you gv.i offline so that you can look at the problem
in more detail.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-15 13:39 ` John David Anglin
@ 2002-04-16 13:14 ` law
2002-04-16 15:25 ` John David Anglin
0 siblings, 1 reply; 32+ messages in thread
From: law @ 2002-04-16 13:14 UTC (permalink / raw)
To: John David Anglin; +Cc: h.m.brand, gcc
In message <200204152027.g3FKRLuZ009642@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
> > However, the code from the actual perl function looks like:
> >
> > cmpib,= 0,%r3,L$1012
> > addil LT'PL_sv_no,%r27
> > addil LT'PL_sv_yes,%r27
> > b L$1013
> > fldd RT'PL_sv_yes(%r1),%fr22
> > L$1012
> > fldd RT'PL_sv_no(%r1),%fr22
> > L$1013
> > fstd %fr22,-272(%r30)
> > b L$0783
> > ldd -272(%r30),%r25
> > [...]
> > L$1017
> > copy %r28,%r25
> > L$0783
> > copy %r25,%r28
> > [restore registers and return]
>
> I tested this with gcc 3.0.3 -O -mpa-risc-2-0 -fPIC (32bit) and the code is:
>
> cmpib,= 0,%r28,L$0940
> addil LT'PL_sv_yes,%r19
> b L$0733
> ldw RT'PL_sv_yes(%r1),%r28
> L$0940
> addil LT'PL_sv_no,%r19
> b L$0733
> ldw RT'PL_sv_no(%r1),%r28
>
> So, this worked with 3.0.3 and we have a regression.
I don't doubt that it worked in the past. My point is that selecting an
FP register to hold an address like this is an exceedingly bad thing to
do. In fact, not assigning the value to a register and instead leaving it
in memory is actually cheaper than assigning it to an FP register.
In fact, from the fragments, it looks like we did something insanely stupid,
why don't we assign the value to %r28 or %r25?
jeff
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
[not found] <no.id>
2002-04-10 15:30 ` John David Anglin
2002-04-11 10:25 ` John David Anglin
@ 2002-04-15 13:39 ` John David Anglin
2002-04-16 13:14 ` law
2 siblings, 1 reply; 32+ messages in thread
From: John David Anglin @ 2002-04-15 13:39 UTC (permalink / raw)
To: John David Anglin; +Cc: law, h.m.brand, gcc
> However, the code from the actual perl function looks like:
>
> cmpib,= 0,%r3,L$1012
> addil LT'PL_sv_no,%r27
> addil LT'PL_sv_yes,%r27
> b L$1013
> fldd RT'PL_sv_yes(%r1),%fr22
> L$1012
> fldd RT'PL_sv_no(%r1),%fr22
> L$1013
> fstd %fr22,-272(%r30)
> b L$0783
> ldd -272(%r30),%r25
> [...]
> L$1017
> copy %r28,%r25
> L$0783
> copy %r25,%r28
> [restore registers and return]
I tested this with gcc 3.0.3 -O -mpa-risc-2-0 -fPIC (32bit) and the code is:
cmpib,= 0,%r28,L$0940
addil LT'PL_sv_yes,%r19
b L$0733
ldw RT'PL_sv_yes(%r1),%r28
L$0940
addil LT'PL_sv_no,%r19
b L$0733
ldw RT'PL_sv_no(%r1),%r28
So, this worked with 3.0.3 and we have a regression.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-11 10:25 ` John David Anglin
2002-04-11 10:43 ` H.Merijn Brand
@ 2002-04-11 11:04 ` law
1 sibling, 0 replies; 32+ messages in thread
From: law @ 2002-04-11 11:04 UTC (permalink / raw)
To: John David Anglin; +Cc: h.m.brand, gcc
In message <200204111714.g3BHEf2h000643@hiauly1.hia.nrc.ca>, "John David
Anglin" writes:
> Interesting. The problem might be in the dynamic loader.
It was definitely the linker. If I recall correctly the problem was related
to the need for the linker to rewrite the inline plabel sequence when the
plabel
was satisfied from a shared library with an insanely large PLT.
jeff
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-11 10:25 ` John David Anglin
@ 2002-04-11 10:43 ` H.Merijn Brand
2002-04-11 11:04 ` law
1 sibling, 0 replies; 32+ messages in thread
From: H.Merijn Brand @ 2002-04-11 10:43 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, law
On Thu 11 Apr 2002 19:14, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > In message <200204111518.g3BFIoZE029965@hiauly1.hia.nrc.ca>, "John David Anglin
> > " writes:
> > > Gcc doesn't generate inline plabels on the PA. It would save one insn
> > > and one data location if we could use these selectors. However, there
> > > have been problems with them in 32bit land for years. I think the
> > > current assembler can handle them but the SOM linker still doesn't
> > > handle them.
> > Actually the SOM linker can handle them, but there are corner cases with
> > very large executables where it's impossible for the SOM linker to properly
> > fixup an inline plabel. For that reason we stopped using them based on
> > a recommendation from HP.
>
> Interesting. The problem might be in the dynamic loader. In the research
> I did for this patch <http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00394.html>,
> I tried using inline plabels with both the HP and GNU assembler/linkers
> since this would have made the definition of ASM_OUTPUT_MI_THUNK considerably
> simpler. The HP assembler/linker compiled my little test PIC program
> with inline plabels. However, when I executed it, the address loaded was
> not the address of a function descriptor for the thunk target function.
> GAS didn't like the LTP/RTP selectors at all. Thus, I was forced to create
> a plabel in the data section. It was a bit tricky to do this in a manner
> that was compatible with both hpux and linux.
I'm off now. If you want me to do more tests, please leave instructions on the
door when you leave. No problems with downloading another source tree, as long
as it is http https or ftp
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
[not found] <no.id>
2002-04-10 15:30 ` John David Anglin
@ 2002-04-11 10:25 ` John David Anglin
2002-04-11 10:43 ` H.Merijn Brand
2002-04-11 11:04 ` law
2002-04-15 13:39 ` John David Anglin
2 siblings, 2 replies; 32+ messages in thread
From: John David Anglin @ 2002-04-11 10:25 UTC (permalink / raw)
To: John David Anglin; +Cc: h.m.brand, gcc, law
> In message <200204111518.g3BFIoZE029965@hiauly1.hia.nrc.ca>, "John David Anglin
> " writes:
> > Gcc doesn't generate inline plabels on the PA. It would save one insn
> > and one data location if we could use these selectors. However, there
> > have been problems with them in 32bit land for years. I think the
> > current assembler can handle them but the SOM linker still doesn't
> > handle them.
> Actually the SOM linker can handle them, but there are corner cases with
> very large executables where it's impossible for the SOM linker to properly
> fixup an inline plabel. For that reason we stopped using them based on
> a recommendation from HP.
Interesting. The problem might be in the dynamic loader. In the research
I did for this patch <http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00394.html>,
I tried using inline plabels with both the HP and GNU assembler/linkers
since this would have made the definition of ASM_OUTPUT_MI_THUNK considerably
simpler. The HP assembler/linker compiled my little test PIC program
with inline plabels. However, when I executed it, the address loaded was
not the address of a function descriptor for the thunk target function.
GAS didn't like the LTP/RTP selectors at all. Thus, I was forced to create
a plabel in the data section. It was a bit tricky to do this in a manner
that was compatible with both hpux and linux.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-11 8:59 ` John David Anglin
2002-04-11 9:15 ` H.Merijn Brand
@ 2002-04-11 9:19 ` law
1 sibling, 0 replies; 32+ messages in thread
From: law @ 2002-04-11 9:19 UTC (permalink / raw)
To: John David Anglin; +Cc: H.Merijn Brand, gcc
In message <200204111518.g3BFIoZE029965@hiauly1.hia.nrc.ca>, "John David
Anglin
" writes:
> Gcc doesn't generate inline plabels on the PA. It would save one insn
> and one data location if we could use these selectors. However, there
> have been problems with them in 32bit land for years. I think the
> current assembler can handle them but the SOM linker still doesn't
> handle them.
Actually the SOM linker can handle them, but there are corner cases with
very large executables where it's impossible for the SOM linker to properly
fixup an inline plabel. For that reason we stopped using them based on
a recommendation from HP.
jeff
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-11 8:59 ` John David Anglin
@ 2002-04-11 9:15 ` H.Merijn Brand
2002-04-11 9:19 ` law
1 sibling, 0 replies; 32+ messages in thread
From: H.Merijn Brand @ 2002-04-11 9:15 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc
[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]
On Thu 11 Apr 2002 17:18, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > On Wed 10 Apr 2002 21:44, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > > > The latest 'snapshot' as in gcc-20020408.tar.bz2
> > >
> > > I'll try the current cvs.
>
> I've duplicated the problem that you found. It's a bug in the GNU linker.
> It's not handling the relocations required for inline plabels correctly.
> The function splay_tree_new_with_allocator seg-faults when it is passed
> a pointer to the function splay_tree_xmalloc_allocate rather than a pointer
> to a function descriptor for splay_tree_xmalloc_allocate. The problem
> is present in both 3.1 and the trunk.
>
> :
>
> The work around is to use the HP linker for the initial bootstrap. I
> recommend just building C, install it, then do another full bootstrap
> using gcc and the GNU linker. You have to use the GNU assembler for
> both builds.
>
> Could you try another build? Just remove "--with-gnu-ld" from your
> script and specify "--with-ld=/usr/ccs/bin/ld". You may want to
> export LD_PXDB=/usr/bin/true to defer invocation of pxdb.
echo "int xxy_us_dummy;" >tmp-dum.c
./xgcc -B./ -B/usr/local/pa20_64/hppa64-hp-hpux11.00/bin/ -isystem /usr/local/pa20_64/hppa64-hp-hpux11.00/include -isystem /usr/local/pa20_64/hppa64-hp-hpux11.00/sys-include -S tmp-dum.c
cc1: internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[2]: *** [s-under] Error 1
make[2]: Leaving directory `/pro/3gl/GNU/gcc-3.0.4/obj/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/pro/3gl/GNU/gcc-3.0.4/obj/gcc'
make: *** [bootstrap-lean] Error 2
I've used Conf-64a and Build-64a and prepared Conf-gcc64 and Build-gcc64
Complete log of Build-64a included in the tgz
105 17:28 Conf-64
106 17:32 Build-64a |& tee gcc-20020408-hpux64
107 17:54 tgz c gcc-20020408-hpux64.tgz Conf-64a Build-64a Conf-gcc64 Build-gcc64 gcc-20020408-hpux64
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
[-- Attachment #2: gcc-20020408-hpux64.tgz --]
[-- Type: application/octet-stream, Size: 17829 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-11 2:19 ` H.Merijn Brand
@ 2002-04-11 8:59 ` John David Anglin
2002-04-11 9:15 ` H.Merijn Brand
2002-04-11 9:19 ` law
0 siblings, 2 replies; 32+ messages in thread
From: John David Anglin @ 2002-04-11 8:59 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: gcc
> On Wed 10 Apr 2002 21:44, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > > The latest 'snapshot' as in gcc-20020408.tar.bz2
> >
> > I'll try the current cvs.
I've duplicated the problem that you found. It's a bug in the GNU linker.
It's not handling the relocations required for inline plabels correctly.
The function splay_tree_new_with_allocator seg-faults when it is passed
a pointer to the function splay_tree_xmalloc_allocate rather than a pointer
to a function descriptor for splay_tree_xmalloc_allocate. The problem
is present in both 3.1 and the trunk.
This problem was introduced on 2002-02-22 when splay-tree.c was changed
to use the above indirect call. The function splay-tree.c is in libiberty.
Libiberty gets built just in stage1 with the HP compiler. The HP compiler
now uses inline plabels (LTP and RTP selectors). The HP assembler and
linker can handle these relocation selectors, but unfortunately not the
GNU linker.
Gcc doesn't generate inline plabels on the PA. It would save one insn
and one data location if we could use these selectors. However, there
have been problems with them in 32bit land for years. I think the
current assembler can handle them but the SOM linker still doesn't
handle them.
The work around is to use the HP linker for the initial bootstrap. I
recommend just building C, install it, then do another full bootstrap
using gcc and the GNU linker. You have to use the GNU assembler for
both builds.
Could you try another build? Just remove "--with-gnu-ld" from your
script and specify "--with-ld=/usr/ccs/bin/ld". You may want to
export LD_PXDB=/usr/bin/true to defer invocation of pxdb.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-10 12:50 ` John David Anglin
@ 2002-04-11 2:19 ` H.Merijn Brand
2002-04-11 8:59 ` John David Anglin
0 siblings, 1 reply; 32+ messages in thread
From: H.Merijn Brand @ 2002-04-11 2:19 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc
On Wed 10 Apr 2002 21:44, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > The latest 'snapshot' as in gcc-20020408.tar.bz2
>
> I'll try the current cvs.
>
> > > This looks like a problem with alloca. Suggest trying 3.1.
> >
> > What URL? (I've got no (working) cvs)
>
> There don't seem to be any 3.1 snaps at ftp://gcc.gnu.org.
Can you make an (anonymous) ftp version available to me?
Do you think I'm /helping/, or just bothering?
Do you think it's worth the trouble?
If I manage - with your help - to build a working HP-UX gcc/64, I'll post the
Conf-64 and Build-64 scripts on the HP-UX forum, because I know there are more
people fighting with exactly the same problem, and none of those has reached
success
C-environment info:
a5:/u/usr/merijn 107 > ll /usr/lib/cpp /usr/ccs/lbin/cpp /opt/langtools/lbin/cpp /wrk/*64/bin/cpp
1114 -r-xr-xr-x 1 bin bin 548864 Sep 20 2001 /opt/langtools/lbin/cpp
194 -r-xr-xr-x 1 bin bin 258048 Nov 7 1997 /usr/ccs/lbin/cpp
1170 lr-xr-xr-t 1 root sys 23 Oct 9 2001 /usr/lib/cpp -> /opt/langtools/lbin/cpp
355 -rwxr-xr-x 1 merijn softwr 151384 Aug 27 2001 /wrk/gcc-3.0.1-64/bin/cpp
556 -rwxr-xr-x 1 merijn bin 666248 Oct 30 21:05 /wrk/pa20_64/bin/cpp
a5:/u/usr/merijn 108 > what !*
what /usr/lib/cpp /usr/ccs/lbin/cpp /opt/langtools/lbin/cpp /wrk/*64/bin/cpp
/usr/lib/cpp:
HP92453-01 B.11.11.04 HP C Preprocessor
$ Sep 8 2000 23:13:51 $
/usr/ccs/lbin/cpp:
HP92453-01 A.11.00.00 HP C (Bundled) Preprocessor
CUPROS_IC23B //1
/ux/core/libs/libc/archive_pa1/libc.a_ID
Oct 21 1997 13:07:38
/opt/langtools/lbin/cpp:
HP92453-01 B.11.11.04 HP C Preprocessor
$ Sep 8 2000 23:13:51 $
/wrk/gcc-3.0.1-64/bin/cpp:
/wrk/pa20_64/bin/cpp:
HP92453-02A.11.00 HP-UX SYMBOLIC DEBUGGER (END.O LP64) $Revision: 75.03 $
a5:/u/usr/merijn 109 > path -w cc
/usr/bin/cc:
LINT B.11.11.04 CXREF B.11.11.04
HP92453-01 B.11.11.25985.GP HP C Compiler
$ Sep 8 2000 23:13:51 $
/usr/bin/cc:
$Revision: 92453-07 linker linker crt0.o B.11.25 010530 $
a5:/u/usr/merijn 110 > swlist -l product | grep -e libc -e header -e ANSI
C-ANSI-C B.11.11.04 HP C/ANSI C Compiler
PHCO_13349 1.0 XCurses header patch.
PHCO_18228 1.0 libc man page cumulative patch
PHCO_23706 1.0 cumulative 10.20 libc compatibility support
PHCO_23770 1.0 libc cumulative patch
PHCO_23963 1.0 libc cumulative header file patch
PHCO_24723 1.0 libc cumulative patch
PHCO_25707 1.0 libc cumulative patch
PHSS_25985 1.0 ANSI C compiler General patch
a5:/u/usr/merijn 111 >
This should reflect the December-2001 QPK patch level. My other hp-11.00 is
already on March-2002, but users prevented me from updating this system so far.
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
[not found] <no.id>
@ 2002-04-10 15:30 ` John David Anglin
2002-04-11 10:25 ` John David Anglin
2002-04-15 13:39 ` John David Anglin
2 siblings, 0 replies; 32+ messages in thread
From: John David Anglin @ 2002-04-10 15:30 UTC (permalink / raw)
To: John David Anglin; +Cc: h.m.brand, gcc
> > The latest 'snapshot' as in gcc-20020408.tar.bz2
>
> I'll try the current cvs.
I don't get the warnings or the seg fault. Have you got a recent header
and libc patch installed on your system? I have PHCO_23963 and PHCO_25707.
You will need to figure out where the warnings are coming from by looking at
the cpp output.
Some of the warnings seem to be from the macro definition for obstack_free
in include/obstack.h. The cast to int might be a problem on hppa64
# if defined __STDC__ && __STDC__
# define obstack_free(h,obj) \
( (h)->temp = (char *) (obj) - (char *) (h)->chunk, \
(((h)->temp > 0 && (h)->temp < (h)->chunk_limit - (char *) (h)->chunk)\
? (int) ((h)->next_free = (h)->object_base \
= (h)->temp + (char *) (h)->chunk) \
: (((obstack_free) ((h), (h)->temp + (char *) (h)->chunk), 0), 0)))
since pointers are 64bit and ints 32bit. This is probably not the problem
since the function version of obstack_free returns void.
What version of cc do you have?
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-10 11:56 ` H.Merijn Brand
@ 2002-04-10 12:50 ` John David Anglin
2002-04-11 2:19 ` H.Merijn Brand
0 siblings, 1 reply; 32+ messages in thread
From: John David Anglin @ 2002-04-10 12:50 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: h.m.brand, gcc
> The latest 'snapshot' as in gcc-20020408.tar.bz2
I'll try the current cvs.
> > This looks like a problem with alloca. Suggest trying 3.1.
>
> What URL? (I've got no (working) cvs)
There don't seem to be any 3.1 snaps at ftp://gcc.gnu.org.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-10 11:21 ` John David Anglin
@ 2002-04-10 11:56 ` H.Merijn Brand
2002-04-10 12:50 ` John David Anglin
0 siblings, 1 reply; 32+ messages in thread
From: H.Merijn Brand @ 2002-04-10 11:56 UTC (permalink / raw)
To: John David Anglin; +Cc: H.Merijn Brand, gcc
Stripped the binutils from the Cc, cause I think we're on a gcc-only track now.
On Wed 10 Apr 2002 20:14, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > [v] gcc still problematic - build log attached (it requests to be sen=
> > t
> > to the gcc people :)
> >
> > a5:/pro/3gl/GNU/gcc-3.0.4 129 > cat Conf-64
>
> It's not totally clear which version your trying to build. It looks like
> 3.0.4 but the files in the log file don't appear to be 3.0.4. In any event,
> there are a various warnings in the log file that are not normal:
The latest 'snapshot' as in gcc-20020408.tar.bz2
The prompt is indeed misleading, but I started this queeste on 3.0.4, so the
structure was already set up. But rest assured: no 3.0.4 code in here.
> cc -Ae +DA2.0W -c -DIN_GCC -g -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I.
> -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../incl
> ude ../../src/gcc/read-rtl.c -o read-rtl.o
> cc: "../../src/gcc/read-rtl.c", line 671: warning 727: Cast truncates pointer in
> to 32 bit integer.
> cc -Ae +DA2.0W -c -DIN_GCC -g -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I.
> -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../incl
> ude ../../src/gcc/bitmap.c -o bitmap.o
> cc: "../../src/gcc/bitmap.c", line 144: warning 727: Cast truncates pointer into
> 32 bit integer.
>
> [...]
>
> c-parse.y:1951: warning: previous rule lacks an ending `;'
> c-parse.y:2017: warning: previous rule lacks an ending `;'
> c-parse.y:2048: warning: previous rule lacks an ending `;'
>
> I have tested the suggested procedure with 3.1 (prerelease) from
> todays cvs and it doesn't have a bootstrap failure in stage 1.
> However, the procedure doesn't work with 3.0.4:
>
> ./gencodes ../../gcc/gcc/config/pa/pa.md > tmp-codes.h
> /bin/sh: 1969 Memory fault(coredump)
>
> This looks like a problem with alloca. Suggest trying 3.1.
What URL? (I've got no (working) cvs)
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-10 3:39 ` H.Merijn Brand
@ 2002-04-10 11:21 ` John David Anglin
2002-04-10 11:56 ` H.Merijn Brand
0 siblings, 1 reply; 32+ messages in thread
From: John David Anglin @ 2002-04-10 11:21 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: gcc, bug-binutils
> [v] gcc still problematic - build log attached (it requests to be sen=
> t
> to the gcc people :)
>
> a5:/pro/3gl/GNU/gcc-3.0.4 129 > cat Conf-64
It's not totally clear which version your trying to build. It looks like
3.0.4 but the files in the log file don't appear to be 3.0.4. In any event,
there are a various warnings in the log file that are not normal:
cc -Ae +DA2.0W -c -DIN_GCC -g -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I.
-I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../incl
ude ../../src/gcc/read-rtl.c -o read-rtl.o
cc: "../../src/gcc/read-rtl.c", line 671: warning 727: Cast truncates pointer in
to 32 bit integer.
cc -Ae +DA2.0W -c -DIN_GCC -g -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I.
-I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../incl
ude ../../src/gcc/bitmap.c -o bitmap.o
cc: "../../src/gcc/bitmap.c", line 144: warning 727: Cast truncates pointer into
32 bit integer.
[...]
c-parse.y:1951: warning: previous rule lacks an ending `;'
c-parse.y:2017: warning: previous rule lacks an ending `;'
c-parse.y:2048: warning: previous rule lacks an ending `;'
I have tested the suggested procedure with 3.1 (prerelease) from
todays cvs and it doesn't have a bootstrap failure in stage 1.
However, the procedure doesn't work with 3.0.4:
./gencodes ../../gcc/gcc/config/pa/pa.md > tmp-codes.h
/bin/sh: 1969 Memory fault(coredump)
This looks like a problem with alloca. Suggest trying 3.1.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-05 9:19 ` John David Anglin
2002-04-07 7:26 ` H.Merijn Brand
@ 2002-04-10 3:39 ` H.Merijn Brand
2002-04-10 11:21 ` John David Anglin
1 sibling, 1 reply; 32+ messages in thread
From: H.Merijn Brand @ 2002-04-10 3:39 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, bug-binutils
[-- Attachment #1: Type: text/plain, Size: 4095 bytes --]
On Fri 05 Apr 2002 18:06, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> Retry following my suggestions. The important points are:
>
> 1) Use a common prefix for your tools (e.g., /usr/local/pa20_64).
[v] Done
> 2) Use --host=hppa64-hp-hpux11.00.
[v] Done
> 3) Export CC="cc -Ae +DA2.0W" for your initial builds of binutils and gcc.
[v] Done
[v] Rebuilt and installed binutils-2.12 again
[v] gcc still problematic - build log attached (it requests to be sent
to the gcc people :)
a5:/pro/3gl/GNU/gcc-3.0.4 129 > cat Conf-64
#!/usr/bin/sh
export CONFIG_SITE=
export CC="cc -Ae +DA2.0W"
export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/opt/imake/bin
rm -rf obj
mkdir obj
cd obj
../src/configure \
--enable-languages=gcc \
--prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 \
--with-gnu-as --with-as=/usr/local/pa20_64/bin/as \
--with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld \
--disable-shared \
--disable-nls \
--host=hppa64-hp-hpux11.00
echo ""
echo "Now start 'Build-64'"
a5:/pro/3gl/GNU/gcc-3.0.4 130 > cat Build-64
#!/usr/bin/sh
export CONFIG_SITE=
export CC="cc -Ae +DA2.0W"
export PATH=.:/usr/local/pa20_64/bin:/pro/local/bin
export PATH=$PATH"":/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/opt/imake/bin
cd obj
make bootstrap-lean
a5:/pro/3gl/GNU/gcc-3.0.4 131 >
a5:/wrk/pa20_64/bin 135 > as --version
GNU assembler 2.12
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
This assembler was configured for a target of `hppa64-hp-hpux11.00'.
a5:/wrk/pa20_64/bin 136 > ar --version
GNU ar 2.12
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
a5:/wrk/pa20_64/bin 137 > file *
addr2line: ELF-64 executable object file - PA-RISC 2.0 (LP64)
ar: ELF-64 executable object file - PA-RISC 2.0 (LP64)
as: ELF-64 executable object file - PA-RISC 2.0 (LP64)
c++: ELF-64 executable object file - PA-RISC 2.0 (LP64)
c++filt: ELF-64 executable object file - PA-RISC 2.0 (LP64)
cpp: ELF-64 executable object file - PA-RISC 2.0 (LP64)
g++: ELF-64 executable object file - PA-RISC 2.0 (LP64)
gas: ELF-64 executable object file - PA-RISC 2.0 (LP64)
gasp: ELF-64 executable object file - PA-RISC 2.0 (LP64)
gcc: ELF-64 executable object file - PA-RISC 2.0 (LP64)
gcc64: ELF-64 executable object file - PA-RISC 2.0 (LP64)
gccbug: commands text
gcov: ELF-64 executable object file - PA-RISC 2.0 (LP64)
gprof: ELF-64 executable object file - PA-RISC 2.0 (LP64)
ld: ELF-64 executable object file - PA-RISC 2.0 (LP64)
nm: ELF-64 executable object file - PA-RISC 2.0 (LP64)
objcopy: ELF-64 executable object file - PA-RISC 2.0 (LP64)
objdump: ELF-64 executable object file - PA-RISC 2.0 (LP64)
ranlib: ELF-64 executable object file - PA-RISC 2.0 (LP64)
readelf: ELF-64 executable object file - PA-RISC 2.0 (LP64)
size: ELF-64 executable object file - PA-RISC 2.0 (LP64)
strings: ELF-64 executable object file - PA-RISC 2.0 (LP64)
strip: ELF-64 executable object file - PA-RISC 2.0 (LP64)
a5:/wrk/pa20_64/bin 138 >
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
[-- Attachment #2: gcc-20020408-hpux64.tgz --]
[-- Type: application/octet-stream, Size: 18321 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-07 7:26 ` H.Merijn Brand
@ 2002-04-07 12:17 ` John David Anglin
0 siblings, 0 replies; 32+ messages in thread
From: John David Anglin @ 2002-04-07 12:17 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: gcc, bug-binutils
> autoconf I *try* to get a recent version installed, but HPUX and AIX
> are not the most wonderfull systems for this package. I /do/
> have these installed, for gcc only.
Install 2.13 for gcc development. It's only needed if you need to update
configure. It shouldn't be needed for normal builds if you start from
a snapshot or use contrib/gcc_update.
> As a side track, how much of what I specify during build is inherited in the
> compiler? Can the /wrk/pa20_64 be ported independent of the way I built it?
> Does the user that receives the dist need the same as and the same ld or can
> it use a different one?
They need to be feature compatible. There are various assembler and linker
checks done by configure.
If you are trying to build with --prefix=/wrk/pa20_64 and install the
final dist to a different directory, there may be problems. The gcc driver
has a builtin dependency on the specified installation directory and it
uses this to locate library and header files. If you specify --with-as,
then it expects to find the assembly in the specified location.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-05 9:19 ` John David Anglin
@ 2002-04-07 7:26 ` H.Merijn Brand
2002-04-07 12:17 ` John David Anglin
2002-04-10 3:39 ` H.Merijn Brand
1 sibling, 1 reply; 32+ messages in thread
From: H.Merijn Brand @ 2002-04-07 7:26 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, bug-binutils
On Fri 05 Apr 2002 18:06, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > > Can you be more specific? I think that once you get a good set of tools
> > > installed you won't have any trouble building 64bit gcc. This is not to
> >
> > Then my tools are probably no good ;)
>
> >From your comments below, I would say they are incorrectly installed.
>
> >
> > > say that that there aren't lots of issues with hppa64 but I am not having
> > > problems doing builds anymore.
> >
> > But you might have /more/ GNU stuff installed in default locations than I h=
> > ave.
> > For example, in the configuration I'll show shortly, it barfs on unsatisfie=
> > d
> > symbol '__umoddi3', which can be found in libgcc.a, which I do not have
> > installed in a default location, and since I'm building with HPc, it won't
> > find it without hints. Now if I set LDFLAGS=3D"-L/usr/local/pa20_64/lib -lg=
> > cc"
>
> If you use HP cc, libgcc.a should not be needed. It gets built in stage1
> by ./xgcc and then installed with the compiler.
was baffled too.
> You need to select a prefix to install your 64-bit tools in (e.g., /opt/gnu64).
I use /wrk/pa20_64 and have /usr/local/pa20_64 symlinked to it
> The prefix can be anywhere but I keep the 64-bit stuff separate from 32-bit
So do I
> som stuff. I build and install my 64-bit binutils tools to the same
> directory and have /opt/gnu64/bin as the first component in PATH to ensure
> that 64-bit tools are used when I do a 64-bit build.
Same here
> You should not have to play with LDFLAGS to bootstrap the compiler.
Found that out too.
> Regarding tools, suggest using GNU make. You should install a 64-bit
GNU make installed as basic make on *ALL* our systems. Native make's just
won't do :)
> versions of binutils. It may also be useful to build bash, bison, gawk,
> texinfo, perl, sed, and possibly autoconf (2.13). You can build these
> with either the HP compiler or 32-bit gcc.
bash only on cywgin (I'm a tcsh addict)
bison 1.34 all over. I'm helping the bison guys with testing on
HP-UX and AIX, so I guess I must be up to date
gawk same as make
texinfo nowhere. I *HATE* the info style of documenting, so I don't
care if installing info stuff fails. I'd even prefer it to
fail. I'd love to see it fallback to the good ol' man pages.
perl hell, I'm a perl5-porter, so I've got several versions up and
running, and the bleading edge version is smoke tested on all
systems every day
sed same as make
autoconf I *try* to get a recent version installed, but HPUX and AIX
are not the most wonderfull systems for this package. I /do/
have these installed, for gcc only.
> > where libgcc can be found in my situation, it is put *before* the libs, mak=
> > ing
> > the needed symbols unfindable, so I commented out LDFLAGS and put in
> > LIBS=3D/usr/local/pa20_64/lib/libgcc.a
> >
> > FYI when reading on, /usr/local/pa20_64 is a symlink to /wrk/pa20_64 becaus=
> > e
> > that LV has more space to play with.
> >
> > > > I've got
> > > >=20
> > > > The latest HP-UX 11.00 with the latest patches
> > > > The latest C compiler (B.11.11.04 HP C/ANSI C Compiler)
> > > > Several ports of gcc
> > > > 3.0.4/32
> > > > 3.0.1/64
> > > > 3.0.2/64
> > > > binutils-2.11.90/64
> > > > binutils-2.12/64
> > >=20
> > > Here are my suggestions. Use the latest binutils. It has fixes that
> > > affect hppa64. Don't use 2.11.90. Build it with the HP ANSI compiler
> > > (ie, use "-Ae +DA2.0W" in your CFLAGS). Gcc may miscompile the
> > > linker causing it to dump core linking shared libraries. Whether
> > > this is still a problem, I'm not sure.
> >
> > I used
> > --8<-- Conf-64
> > #!/usr/bin/sh
> >
> > export CONFIG_SITE=3D
> > export CC=3Dcc
>
> Change this to
> export CC="cc -Ae +DA2.0W"
I will
> > export CFLAGS=3D"-Ae -O +DA2.0W"
> > #export LDFLAGS=3D"-L/usr/local/pa20_64/lib -lgcc"
> > export LIBS=3D/usr/local/pa20_64/lib/libgcc.a
>
> Delete these.
Consider it done
> > export PATH=3D.
> > export PATH=3D$PATH"":/u/usr/merijn/bin/private:/u/usr/merijn/bin
> > export PATH=3D$PATH"":/pro/local/bin:/pro/bin
> > export PATH=3D$PATH"":/usr/bin:/usr/bin/X11:/opt/ansic/bin
> > export PATH=3D$PATH"":/usr/sbin:/etc:/sbin:/usr/lib:/usr/ccs/bin:/opt/langt=
> > ools/bin
> > export PATH=3D$PATH"":/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin
> >
> > configure \
> > --prefix=3D/wrk/pa20_64 --with-local-prefix=3D/wrk/pa20_64 \
> > --disable-shared \
> > --disable-nls \
> > --enable-multilib \
> > --enable-threads
>
> Use a modification of what I sent. --with-local-prefix probably isn't
> needed. You don't need --enable-multilib or --enable-threads. There
> isn't any thread support yet and no multilibs.
Grrr, but at least it proves I read /beyond/ the surface.
> > -->8---
> >
>
> The patch below is incorrect. The hppa2.0w-hp-hpux11* target is actually
> the 32-bit som target on a 2.0w machine. It shouldn't be changed to
> 64-bit. Same for gcc config.
An auto-detect, or configure help would be nice then. I /did/ try with
specifying the host like that, but also got stuck somewhere, so I thought this
would be a more clean way to go.
> You want to configure binutils with something like
>
> --host=hppa64-hp-hpux11.11 --prefix=/opt/gnu64 --disable-nls
>
> If you are using a 11.00 system --host should be hppa64-hp-hpux11.00. You
> need to specify --host, or a complete set of --host, --build and --target
> to do a 64-bit build. The default guess is for 32-bit tools.
Systems are down now, expect some positive message early this week.
> > But needed the followin patches:
> > --8<-- binutils-2.12.diff
> > --- binutils-2.12.org/configure.in 2002-03-08 20:45:10.000000000 +0100
> > +++ binutils-2.12/configure.in 2002-04-05 13:17:26.000000000 +0200
> > @@ -722,8 +722,10 @@
> > hppa*-*-*elf* | \
> > hppa*-*-linux-gnu* | \
> > hppa*-*-lites* | \
> > + hppa*2.0w*-*-* | \
> > hppa*64*-*-*)
>
> [...]
>
> > > These are the gcc configure options that I use:
> > >=20
> > > --host=3Dhppa64-hp-hpux11.11 --with-gnu-as --with-as=3D/opt/gnu64/bin/as
> > =20
> > That's a HP-UX 11i
>
> Yes. It works identically to 11.00.
>
> > =20
> > > --with-gnu-ld --with-ld=3D/opt/gnu64/bin/ld --disable-nls --prefix=3D/opt=
> > /gnu64
> >
> > This is what I went for
> > --8<-- Conf-64
> > #!/usr/bin/sh
> >
> > export CONFIG_SITE=3D
> > export CC=3D"cc -Ae +DA2.0W"
> > export PATH=3D.:/u/usr/merijn/bin/private:/u/usr/merijn/bin
> > export PATH=3D$PATH"":/pro/local/bin:/pro/bin:/usr/bin:/usr/bin/X11
> > export PATH=3D$PATH"":/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
> > export PATH=3D$PATH"":/usr/lib:/usr/contrib/bin:/usr/contrib/bin/X11:/opt/i=
> > make/bin
> > export PATH=3D$PATH"":/wrk/pa20_64/bin:/wrk/GNUpro/bin
>
> When you do a 64-bit build, make sure that the 64-bit tools are before
They are.
> the 32-bit and HP tools. Some have the same name so you want to be sure
> that your using the correct tools. The HP compiler knows how to find
> its tools.
As a side track, how much of what I specify during build is inherited in the
compiler? Can the /wrk/pa20_64 be ported independent of the way I built it?
Does the user that receives the dist need the same as and the same ld or can
it use a different one?
> >
> > rm -rf obj
> > mkdir obj
> > cd obj
> > =2E./src/configure \
> > --enable-languages=3Dgcc \
> > --prefix=3D/usr/local/pa20_64 --with-local-prefix=3D/usr/local/pa20_64 =
> > \
> > --with-gnu-as \
> > --with-gnu-ld \
> > --disable-shared \
> > --disable-nls \
> > --enable-multilib \
> > --enable-threads \
> > --with-system-zlib
> >
> > echo ""
> > echo "Now start 'Build-64'"
> > -->8---
> >
>
> Again, the patch below is wrong and unnecessary. You need to specify
> --host properly. I suggest removing --enable-multilib, --enable-threads
> and --with-system-zlib. The system zlib probably has the security bug.
No, all my zlib's are up to date. The security bug made me choose for this
option in the first place.
> >
> > Of course after patchin with
> > --8<--
> > --- src/configure.in.org 2002-04-05 14:16:10.000000000 +0200
> > +++ src/configure.in 2002-04-05 14:16:31.000000000 +0200
> > @@ -284,6 +284,7 @@
> > # hpux11 in 64bit mode has libraries in a weird place. Arrange to find
> > # them automatically.
> > case "${host}" in
> > + hppa*2.0w*-*-hpux11* | \
> > hppa*64*-*-hpux11*)=09
>
> [...]
>
> > The build comes amazingly far, but core dumps like
> >
> > echo "int xxy_us_dummy;" >tmp-dum.c
> > =2E/xgcc -B./ -B/usr/local/pa20_64/hppa2.0w-hp-hpux11.00/bin/ -isystem /usr=
> > /local/pa20_64/hppa2.0w-hp-hpux11.00/include -isystem /usr/local/pa20_64/hp=
> > pa2.0w-hp-hpux11.00/sys-include -S tmp-dum.c
> > cc1: internal error: Segmentation fault
>
> > No core dump.
> >
> > Should I go on?
>
> Retry following my suggestions. The important points are:
>
> 1) Use a common prefix for your tools (e.g., /usr/local/pa20_64).
> 2) Use --host=hppa64-hp-hpux11.00.
> 3) Export CC="cc -Ae +DA2.0W" for your initial builds of binutils and gcc.
Thanks so far. I'll keep you posted.
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-05 4:51 ` H.Merijn Brand
2002-04-05 5:01 ` H.Merijn Brand
@ 2002-04-05 9:19 ` John David Anglin
2002-04-07 7:26 ` H.Merijn Brand
2002-04-10 3:39 ` H.Merijn Brand
1 sibling, 2 replies; 32+ messages in thread
From: John David Anglin @ 2002-04-05 9:19 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: gcc, bug-binutils
> > Can you be more specific? I think that once you get a good set of tools
> > installed you won't have any trouble building 64bit gcc. This is not to
>
> Then my tools are probably no good ;)
From your comments below, I would say they are incorrectly installed.
>
> > say that that there aren't lots of issues with hppa64 but I am not having
> > problems doing builds anymore.
>
> But you might have /more/ GNU stuff installed in default locations than I h=
> ave.
> For example, in the configuration I'll show shortly, it barfs on unsatisfie=
> d
> symbol '__umoddi3', which can be found in libgcc.a, which I do not have
> installed in a default location, and since I'm building with HPc, it won't
> find it without hints. Now if I set LDFLAGS=3D"-L/usr/local/pa20_64/lib -lg=
> cc"
If you use HP cc, libgcc.a should not be needed. It gets built in stage1
by ./xgcc and then installed with the compiler.
You need to select a prefix to install your 64-bit tools in (e.g., /opt/gnu64).
The prefix can be anywhere but I keep the 64-bit stuff separate from 32-bit
som stuff. I build and install my 64-bit binutils tools to the same
directory and have /opt/gnu64/bin as the first component in PATH to ensure
that 64-bit tools are used when I do a 64-bit build.
You should not have to play with LDFLAGS to bootstrap the compiler.
Regarding tools, suggest using GNU make. You should install a 64-bit
versions of binutils. It may also be useful to build bash, bison, gawk,
texinfo, perl, sed, and possibly autoconf (2.13). You can build these
with either the HP compiler or 32-bit gcc.
> where libgcc can be found in my situation, it is put *before* the libs, mak=
> ing
> the needed symbols unfindable, so I commented out LDFLAGS and put in
> LIBS=3D/usr/local/pa20_64/lib/libgcc.a
>
> FYI when reading on, /usr/local/pa20_64 is a symlink to /wrk/pa20_64 becaus=
> e
> that LV has more space to play with.
>
> > > I've got
> > >=20
> > > The latest HP-UX 11.00 with the latest patches
> > > The latest C compiler (B.11.11.04 HP C/ANSI C Compiler)
> > > Several ports of gcc
> > > 3.0.4/32
> > > 3.0.1/64
> > > 3.0.2/64
> > > binutils-2.11.90/64
> > > binutils-2.12/64
> >=20
> > Here are my suggestions. Use the latest binutils. It has fixes that
> > affect hppa64. Don't use 2.11.90. Build it with the HP ANSI compiler
> > (ie, use "-Ae +DA2.0W" in your CFLAGS). Gcc may miscompile the
> > linker causing it to dump core linking shared libraries. Whether
> > this is still a problem, I'm not sure.
>
> I used
> --8<--- Conf-64
> #!/usr/bin/sh
>
> export CONFIG_SITE=3D
> export CC=3Dcc
Change this to
export CC="cc -Ae +DA2.0W"
> export CFLAGS=3D"-Ae -O +DA2.0W"
> #export LDFLAGS=3D"-L/usr/local/pa20_64/lib -lgcc"
> export LIBS=3D/usr/local/pa20_64/lib/libgcc.a
Delete these.
> export PATH=3D.
> export PATH=3D$PATH"":/u/usr/merijn/bin/private:/u/usr/merijn/bin
> export PATH=3D$PATH"":/pro/local/bin:/pro/bin
> export PATH=3D$PATH"":/usr/bin:/usr/bin/X11:/opt/ansic/bin
> export PATH=3D$PATH"":/usr/sbin:/etc:/sbin:/usr/lib:/usr/ccs/bin:/opt/langt=
> ools/bin
> export PATH=3D$PATH"":/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin
>
> configure \
> --prefix=3D/wrk/pa20_64 --with-local-prefix=3D/wrk/pa20_64 \
> --disable-shared \
> --disable-nls \
> --enable-multilib \
> --enable-threads
Use a modification of what I sent. --with-local-prefix probably isn't
needed. You don't need --enable-multilib or --enable-threads. There
isn't any thread support yet and no multilibs.
> -->8---
>
The patch below is incorrect. The hppa2.0w-hp-hpux11* target is actually
the 32-bit som target on a 2.0w machine. It shouldn't be changed to
64-bit. Same for gcc config.
You want to configure binutils with something like
--host=hppa64-hp-hpux11.11 --prefix=/opt/gnu64 --disable-nls
If you are using a 11.00 system --host should be hppa64-hp-hpux11.00. You
need to specify --host, or a complete set of --host, --build and --target
to do a 64-bit build. The default guess is for 32-bit tools.
> But needed the followin patches:
> --8<--- binutils-2.12.diff
> --- binutils-2.12.org/configure.in 2002-03-08 20:45:10.000000000 +0100
> +++ binutils-2.12/configure.in 2002-04-05 13:17:26.000000000 +0200
> @@ -722,8 +722,10 @@
> hppa*-*-*elf* | \
> hppa*-*-linux-gnu* | \
> hppa*-*-lites* | \
> + hppa*2.0w*-*-* | \
> hppa*64*-*-*)
[...]
> > These are the gcc configure options that I use:
> >=20
> > --host=3Dhppa64-hp-hpux11.11 --with-gnu-as --with-as=3D/opt/gnu64/bin/as
> =20
> That's a HP-UX 11i
Yes. It works identically to 11.00.
> =20
> > --with-gnu-ld --with-ld=3D/opt/gnu64/bin/ld --disable-nls --prefix=3D/opt=
> /gnu64
>
> This is what I went for
> --8<--- Conf-64
> #!/usr/bin/sh
>
> export CONFIG_SITE=3D
> export CC=3D"cc -Ae +DA2.0W"
> export PATH=3D.:/u/usr/merijn/bin/private:/u/usr/merijn/bin
> export PATH=3D$PATH"":/pro/local/bin:/pro/bin:/usr/bin:/usr/bin/X11
> export PATH=3D$PATH"":/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
> export PATH=3D$PATH"":/usr/lib:/usr/contrib/bin:/usr/contrib/bin/X11:/opt/i=
> make/bin
> export PATH=3D$PATH"":/wrk/pa20_64/bin:/wrk/GNUpro/bin
When you do a 64-bit build, make sure that the 64-bit tools are before
the 32-bit and HP tools. Some have the same name so you want to be sure
that your using the correct tools. The HP compiler knows how to find
its tools.
>
> rm -rf obj
> mkdir obj
> cd obj
> =2E./src/configure \
> --enable-languages=3Dgcc \
> --prefix=3D/usr/local/pa20_64 --with-local-prefix=3D/usr/local/pa20_64 =
> \
> --with-gnu-as \
> --with-gnu-ld \
> --disable-shared \
> --disable-nls \
> --enable-multilib \
> --enable-threads \
> --with-system-zlib
>
> echo ""
> echo "Now start 'Build-64'"
> -->8---
>
Again, the patch below is wrong and unnecessary. You need to specify
--host properly. I suggest removing --enable-multilib, --enable-threads
and --with-system-zlib. The system zlib probably has the security bug.
>
> Of course after patchin with
> --8<---
> --- src/configure.in.org 2002-04-05 14:16:10.000000000 +0200
> +++ src/configure.in 2002-04-05 14:16:31.000000000 +0200
> @@ -284,6 +284,7 @@
> # hpux11 in 64bit mode has libraries in a weird place. Arrange to find
> # them automatically.
> case "${host}" in
> + hppa*2.0w*-*-hpux11* | \
> hppa*64*-*-hpux11*)=09
[...]
> The build comes amazingly far, but core dumps like
>
> echo "int xxy_us_dummy;" >tmp-dum.c
> =2E/xgcc -B./ -B/usr/local/pa20_64/hppa2.0w-hp-hpux11.00/bin/ -isystem /usr=
> /local/pa20_64/hppa2.0w-hp-hpux11.00/include -isystem /usr/local/pa20_64/hp=
> pa2.0w-hp-hpux11.00/sys-include -S tmp-dum.c
> cc1: internal error: Segmentation fault
> No core dump.
>
> Should I go on?
Retry following my suggestions. The important points are:
1) Use a common prefix for your tools (e.g., /usr/local/pa20_64).
2) Use --host=hppa64-hp-hpux11.00.
3) Export CC="cc -Ae +DA2.0W" for your initial builds of binutils and gcc.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-05 4:51 ` H.Merijn Brand
@ 2002-04-05 5:01 ` H.Merijn Brand
2002-04-05 9:19 ` John David Anglin
1 sibling, 0 replies; 32+ messages in thread
From: H.Merijn Brand @ 2002-04-05 5:01 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, bug-binutils
[-- Attachment #1: Type: text/plain, Size: 385 bytes --]
On Fri 05 Apr 2002 14:49, H.Merijn Brand <h.m.brand@hccnet.nl> wrote:
Log for gcc was missing
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
[-- Attachment #2: gcc-Build-64.log.gz --]
[-- Type: application/octet-stream, Size: 17282 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
[not found] ` <200204041958.g34JwTbA011272@hiauly1.hia.nrc.ca>
@ 2002-04-05 4:51 ` H.Merijn Brand
2002-04-05 5:01 ` H.Merijn Brand
2002-04-05 9:19 ` John David Anglin
0 siblings, 2 replies; 32+ messages in thread
From: H.Merijn Brand @ 2002-04-05 4:51 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc, bug-binutils
[-- Attachment #1: Type: text/plain, Size: 11620 bytes --]
On Thu 04 Apr 2002 21:58, "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:
> > As I've seen on the gcc web site, HP-UX 11.00 has been promoted to primary
> > target site. I've got no trouble building gcc in 32 bit mode, but building a
> > 64bit gcc is still almost impossible.
>
> Can you be more specific? I think that once you get a good set of tools
> installed you won't have any trouble building 64bit gcc. This is not to
Then my tools are probably no good ;)
> say that that there aren't lots of issues with hppa64 but I am not having
> problems doing builds anymore.
But you might have /more/ GNU stuff installed in default locations than I have.
For example, in the configuration I'll show shortly, it barfs on unsatisfied
symbol '__umoddi3', which can be found in libgcc.a, which I do not have
installed in a default location, and since I'm building with HPc, it won't
find it without hints. Now if I set LDFLAGS="-L/usr/local/pa20_64/lib -lgcc"
where libgcc can be found in my situation, it is put *before* the libs, making
the needed symbols unfindable, so I commented out LDFLAGS and put in
LIBS=/usr/local/pa20_64/lib/libgcc.a
FYI when reading on, /usr/local/pa20_64 is a symlink to /wrk/pa20_64 because
that LV has more space to play with.
> > I've got
> >
> > The latest HP-UX 11.00 with the latest patches
> > The latest C compiler (B.11.11.04 HP C/ANSI C Compiler)
> > Several ports of gcc
> > 3.0.4/32
> > 3.0.1/64
> > 3.0.2/64
> > binutils-2.11.90/64
> > binutils-2.12/64
>
> Here are my suggestions. Use the latest binutils. It has fixes that
> affect hppa64. Don't use 2.11.90. Build it with the HP ANSI compiler
> (ie, use "-Ae +DA2.0W" in your CFLAGS). Gcc may miscompile the
> linker causing it to dump core linking shared libraries. Whether
> this is still a problem, I'm not sure.
I used
--8<--- Conf-64
#!/usr/bin/sh
export CONFIG_SITE=
export CC=cc
export CFLAGS="-Ae -O +DA2.0W"
#export LDFLAGS="-L/usr/local/pa20_64/lib -lgcc"
export LIBS=/usr/local/pa20_64/lib/libgcc.a
export PATH=.
export PATH=$PATH"":/u/usr/merijn/bin/private:/u/usr/merijn/bin
export PATH=$PATH"":/pro/local/bin:/pro/bin
export PATH=$PATH"":/usr/bin:/usr/bin/X11:/opt/ansic/bin
export PATH=$PATH"":/usr/sbin:/etc:/sbin:/usr/lib:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin
configure \
--prefix=/wrk/pa20_64 --with-local-prefix=/wrk/pa20_64 \
--disable-shared \
--disable-nls \
--enable-multilib \
--enable-threads
-->8---
But needed the followin patches:
--8<--- binutils-2.12.diff
--- binutils-2.12.org/configure.in 2002-03-08 20:45:10.000000000 +0100
+++ binutils-2.12/configure.in 2002-04-05 13:17:26.000000000 +0200
@@ -722,8 +722,10 @@
hppa*-*-*elf* | \
hppa*-*-linux-gnu* | \
hppa*-*-lites* | \
+ hppa*2.0w*-*-* | \
hppa*64*-*-*)
# Do configure ld/binutils/gas for this case.
+ echo " ############# 64bit ################### ($noconfigdirs)" >&2
;;
hppa*-*-*)
# HP's C compiler doesn't handle Emacs correctly (but on BSD and Mach
--- binutils-2.12.org/bfd/config.bfd 2002-02-13 21:45:46.000000000 +0100
+++ binutils-2.12/bfd/config.bfd 2002-04-05 13:10:23.000000000 +0200
@@ -292,6 +292,7 @@
targ_defvec=bfd_elf64_hppa_linux_vec
targ_selvecs=bfd_elf64_hppa_vec
;;
+ hppa*2.0w*-*-hpux11* | \
hppa*64*-*-hpux11*)
targ_defvec=bfd_elf64_hppa_vec
targ_selvecs=bfd_elf64_hppa_linux_vec
--- binutils-2.12.org/bfd/configure.host 2002-01-22 01:47:21.000000000 +0100
+++ binutils-2.12/bfd/configure.host 2002-04-05 13:10:41.000000000 +0200
@@ -21,6 +21,7 @@
alpha*-*-*) host64=true; HOST_64BIT_TYPE=long ;;
+hppa*2.0w*-*-hpux* | \
hppa*64*-*-hpux*) HDEFINES=-DHOST_HPPAHPUX;
host64=true; HOST_64BIT_TYPE=long ;;
hppa*-*-hpux*) HDEFINES=-DHOST_HPPAHPUX ;;
--- binutils-2.12.org/gas/configure 2002-02-26 11:35:27.000000000 +0100
+++ binutils-2.12/gas/configure 2002-04-05 13:11:01.000000000 +0200
@@ -2377,6 +2377,7 @@
hppa-*-osf*) fmt=som em=hppa ;;
hppa-*-rtems*) fmt=elf em=hppa ;;
hppa-*-hpux11*) case ${cpu} in
+ hppa*2.0w* | \
hppa*64*)
fmt=elf em=hppa64 ;;
hppa*)
--- binutils-2.12.org/gas/configure.in 2002-02-26 11:35:27.000000000 +0100
+++ binutils-2.12/gas/configure.in 2002-04-05 13:11:17.000000000 +0200
@@ -227,6 +227,7 @@
hppa-*-osf*) fmt=som em=hppa ;;
hppa-*-rtems*) fmt=elf em=hppa ;;
hppa-*-hpux11*) case ${cpu} in
+ hppa*2.0w* | \
hppa*64*)
fmt=elf em=hppa64 ;;
hppa*)
--- binutils-2.12.org/ld/configure.tgt 2002-02-20 06:26:22.000000000 +0100
+++ binutils-2.12/ld/configure.tgt 2002-04-05 13:07:56.000000000 +0200
@@ -309,6 +309,7 @@
m68*-*-rtemscoff*) targ_emul=m68kcoff ;;
m68*-*-rtems*) targ_emul=m68kelf ;;
hppa*64*-*-linux-gnu*) targ_emul=hppa64linux ;;
+hppa*2.0w*-*) targ_emul=elf64hppa ;;
hppa*64*-*) targ_emul=elf64hppa ;;
hppa*-*-linux-gnu*) targ_emul=hppalinux ;;
hppa*-*-*elf*) targ_emul=hppaelf ;;
-->8---
Conf-64 now finishes to the end.
Now I use
--8<--- Build-64
#!/usr/bin/sh
export CONFIG_SITE=
export CC=cc
export CFLAGS="-Ae -O +DA2.0W"
#export LDFLAGS="-L/usr/local/pa20_64/lib -lgcc"
export LIBS=/usr/local/pa20_64/lib/libgcc.a
export PATH=.
export PATH=$PATH"":/u/usr/merijn/bin/private:/u/usr/merijn/bin
export PATH=$PATH"":/pro/local/bin:/pro/bin
export PATH=$PATH"":/usr/bin:/usr/bin/X11:/opt/ansic/bin
export PATH=$PATH"":/usr/sbin:/etc:/sbin:/usr/lib:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin
make
-->8---
After the first run I changed 'make' to 'make -i' and reran
the log is attached
a5:/wrk/pa20_64/bin 189 > find * -newer ld.pl -type f | xargs file
addr2line: ELF-64 executable object file - PA-RISC 2.0 (LP64)
ar: ELF-64 executable object file - PA-RISC 2.0 (LP64)
as: ELF-64 executable object file - PA-RISC 2.0 (LP64)
c++filt: ELF-64 executable object file - PA-RISC 2.0 (LP64)
gas: ELF-64 executable object file - PA-RISC 2.0 (LP64)
gasp: ELF-64 executable object file - PA-RISC 2.0 (LP64)
gprof: ELF-64 executable object file - PA-RISC 2.0 (LP64)
ld: ELF-64 executable object file - PA-RISC 2.0 (LP64)
nm: ELF-64 executable object file - PA-RISC 2.0 (LP64)
objcopy: ELF-64 executable object file - PA-RISC 2.0 (LP64)
objdump: ELF-64 executable object file - PA-RISC 2.0 (LP64)
ranlib: ELF-64 executable object file - PA-RISC 2.0 (LP64)
readelf: ELF-64 executable object file - PA-RISC 2.0 (LP64)
size: ELF-64 executable object file - PA-RISC 2.0 (LP64)
strings: ELF-64 executable object file - PA-RISC 2.0 (LP64)
strip: ELF-64 executable object file - PA-RISC 2.0 (LP64)
a5:/wrk/pa20_64/bin 190 >
Now I should have a working set of binutils, I guess (FTR, I built my previous
set with gcc-3.0.2/64)
> For gcc, use either the 3.1 branch or the unstable 3.2 trunk. You
I'll go for the gcc-20020401.tar.bz2 version I snatched from snapshot
> should be able to bootstrap it using CC="cc -Ae +DA2.0W" or with
> a working version of gcc for hppa64. Use the GNU binutils and specify
> the locations for as and ld using --with-as and --with-ld. Run
> the testsuite to see if things are working. There are some problems
> with shared libraries so it's probably better not to specify
> --enable-shared in your configure options.
>
> These are the gcc configure options that I use:
>
> --host=hppa64-hp-hpux11.11 --with-gnu-as --with-as=/opt/gnu64/bin/as
That's a HP-UX 11i
> --with-gnu-ld --with-ld=/opt/gnu64/bin/ld --disable-nls --prefix=/opt/gnu64
This is what I went for
--8<--- Conf-64
#!/usr/bin/sh
export CONFIG_SITE=
export CC="cc -Ae +DA2.0W"
export PATH=.:/u/usr/merijn/bin/private:/u/usr/merijn/bin
export PATH=$PATH"":/pro/local/bin:/pro/bin:/usr/bin:/usr/bin/X11
export PATH=$PATH"":/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/usr/lib:/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin
export PATH=$PATH"":/wrk/pa20_64/bin:/wrk/GNUpro/bin
rm -rf obj
mkdir obj
cd obj
../src/configure \
--enable-languages=gcc \
--prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 \
--with-gnu-as \
--with-gnu-ld \
--disable-shared \
--disable-nls \
--enable-multilib \
--enable-threads \
--with-system-zlib
echo ""
echo "Now start 'Build-64'"
-->8---
Of course after patchin with
--8<---
--- src/configure.in.org 2002-04-05 14:16:10.000000000 +0200
+++ src/configure.in 2002-04-05 14:16:31.000000000 +0200
@@ -284,6 +284,7 @@
# hpux11 in 64bit mode has libraries in a weird place. Arrange to find
# them automatically.
case "${host}" in
+ hppa*2.0w*-*-hpux11* | \
hppa*64*-*-hpux11*)
withoptions="$withoptions -x-libraries=/usr/lib/pa20_64 -x-includes=/usr/X11R6/include"
;;
@@ -567,6 +568,7 @@
noconfigdirs=""
case "${host}" in
+ hppa*2.0w*-*-* |\
hppa*64*-*-*)
noconfigdirs="$noconfigdirs byacc"
;;
@@ -771,6 +773,7 @@
hppa*-*-*elf* | \
parisc*-*-linux* | hppa*-*-linux* | \
hppa*-*-lites* | \
+ hppa*2.0w*-*-* | \
hppa*64*-*-*)
noconfigdirs="$noconfigdirs ${libgcj}"
# Do configure ld/binutils/gas for this case.
--- src/gcc/config.gcc.org 2002-04-05 14:14:51.000000000 +0200
+++ src/gcc/config.gcc 2002-04-05 14:14:58.000000000 +0200
@@ -917,6 +917,7 @@
install_headers_dir=install-headers-cpio
use_collect2=yes
;;
+hppa*2.0w*-*-hpux11* | \
hppa*64*-*-hpux11*)
xm_defines=POSIX
tm_file="pa/pa64-start.h ${tm_file} pa/pa64-regs.h pa/long_double.h pa/elf.h pa/pa-hpux.h pa/pa-hpux11.h pa/pa-64.h pa/pa64-hpux.h"
-->8---
Now I use
--8<--- Build-64
#!/usr/bin/sh
export CONFIG_SITE=
export CC="cc -Ae +DA2.0W"
export PATH=.:/u/usr/merijn/bin/private:/u/usr/merijn/bin
export PATH=$PATH"":/pro/local/bin:/pro/bin:/usr/bin:/usr/bin/X11
export PATH=$PATH"":/opt/ansic/bin:/usr/ccs/bin:/opt/langtools/bin
export PATH=$PATH"":/usr/lib:/usr/contrib/bin:/usr/contrib/bin/X11:/opt/imake/bin
export PATH=$PATH"":/wrk/pa20_64/bin:/wrk/GNUpro/bin
cd obj
make bootstrap-lean
-->8---
The build comes amazingly far, but core dumps like
echo "int xxy_us_dummy;" >tmp-dum.c
./xgcc -B./ -B/usr/local/pa20_64/hppa2.0w-hp-hpux11.00/bin/ -isystem /usr/local/pa20_64/hppa2.0w-hp-hpux11.00/include -isystem /usr/local/pa20_64/hppa2.0w-hp-hpux11.00/sys-include -S tmp-dum.c
cc1: internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[2]: *** [s-under] Error 1
make[2]: Leaving directory `/pro/3gl/GNU/gcc-3.0.4/obj/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/pro/3gl/GNU/gcc-3.0.4/obj/gcc'
make: *** [bootstrap-lean] Error 2
No core dump.
Should I go on?
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
[-- Attachment #2: binutils-2.12-Build-64.log.gz --]
[-- Type: application/octet-stream, Size: 3865 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
@ 2002-04-04 12:02 John David Anglin
0 siblings, 0 replies; 32+ messages in thread
From: John David Anglin @ 2002-04-04 12:02 UTC (permalink / raw)
To: gcc
> As I've seen on the gcc web site, HP-UX 11.00 has been promoted to primary
> target site. I've got no trouble building gcc in 32 bit mode, but building a
> 64bit gcc is still almost impossible.
Can you be more specific? I think that once you get a good set of tools
installed you won't have any trouble building 64bit gcc. This is not to
say that that there aren't lots of issues with hppa64 but I am not having
problems doing builds anymore.
> I've got
>
> The latest HP-UX 11.00 with the latest patches
> The latest C compiler (B.11.11.04 HP C/ANSI C Compiler)
> Several ports of gcc
> 3.0.4/32
> 3.0.1/64
> 3.0.2/64
> binutils-2.11.90/64
> binutils-2.12/64
Here are my suggestions. Use the latest binutils. It has fixes that
affect hppa64. Don't use 2.11.90. Build it with the HP ANSI compiler
(ie, use "-Ae +DA2.0W" in your CFLAGS). Gcc may miscompile the
linker causing it to dump core linking shared libraries. Whether
this is still a problem, I'm not sure.
For gcc, use either the 3.1 branch or the unstable 3.2 trunk. You
should be able to bootstrap it using CC="cc -Ae +DA2.0W" or with
a working version of gcc for hppa64. Use the GNU binutils and specify
the locations for as and ld using --with-as and --with-ld. Run
the testsuite to see if things are working. There are some problems
with shared libraries so it's probably better not to specify
--enable-shared in your configure options.
These are the gcc configure options that I use:
--host=hppa64-hp-hpux11.11 --with-gnu-as --with-as=/opt/gnu64/bin/as --with-gnu-ld --with-ld=/opt/gnu64/bin/ld --disable-nls --prefix=/opt/gnu64
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: gcc-64 on HP-UX 11.00
2002-04-04 2:03 H.Merijn Brand
@ 2002-04-04 8:22 ` law
[not found] ` <200204041958.g34JwTbA011272@hiauly1.hia.nrc.ca>
1 sibling, 0 replies; 32+ messages in thread
From: law @ 2002-04-04 8:22 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: gcc
In message <20020404113717.E7B3.H.M.BRAND@hccnet.nl>, "H.Merijn Brand" writes:
> As I've seen on the gcc web site, HP-UX 11.00 has been promoted to primary
> target site. I've got no trouble building gcc in 32 bit mode, but building a
> 64bit gcc is still almost impossible.
Correct. 32bit builds should go fine. 64bit builds are a pain.
> Is there a preferred way to build from the latest snapshot? Do you want more
> specific messages about the problems?
The preferred way is to always have a previous 64bit compiler available --
building the 64bit PA tools is exceedingly hard using a 32bit GCC or
the HP provided compilers.
Even if you have 64bit PA tools, you're going to run into problems as that
toolchain doesn't receive nearly the attention that the 32bit toolchain
receives.
jeff
^ permalink raw reply [flat|nested] 32+ messages in thread
* gcc-64 on HP-UX 11.00
@ 2002-04-04 2:03 H.Merijn Brand
2002-04-04 8:22 ` law
[not found] ` <200204041958.g34JwTbA011272@hiauly1.hia.nrc.ca>
0 siblings, 2 replies; 32+ messages in thread
From: H.Merijn Brand @ 2002-04-04 2:03 UTC (permalink / raw)
To: gcc
As I've seen on the gcc web site, HP-UX 11.00 has been promoted to primary
target site. I've got no trouble building gcc in 32 bit mode, but building a
64bit gcc is still almost impossible.
Is there a preferred way to build from the latest snapshot? Do you want more
specific messages about the problems?
I'm not into the gcc sources, but somehow I seem to be willing to function as
a compile farm.
I've got
The latest HP-UX 11.00 with the latest patches
The latest C compiler (B.11.11.04 HP C/ANSI C Compiler)
Several ports of gcc
3.0.4/32
3.0.1/64
3.0.2/64
binutils-2.11.90/64
binutils-2.12/64
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2002-04-16 22:23 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20020411221308.416D.H.M.BRAND@hccnet.nl>
[not found] ` <200204112027.g3BKR6DK001129@hiauly1.hia.nrc.ca>
2002-04-12 3:19 ` gcc-64 on HP-UX 11.00 H.Merijn Brand
2002-04-12 4:39 ` H.Merijn Brand
2002-04-12 5:08 ` H.Merijn Brand
2002-04-12 9:34 ` John David Anglin
2002-04-13 10:40 ` John David Anglin
2002-04-15 8:45 ` law
2002-04-15 9:46 ` John David Anglin
2002-04-15 10:05 ` law
2002-04-15 11:42 ` John David Anglin
[not found] <no.id>
2002-04-10 15:30 ` John David Anglin
2002-04-11 10:25 ` John David Anglin
2002-04-11 10:43 ` H.Merijn Brand
2002-04-11 11:04 ` law
2002-04-15 13:39 ` John David Anglin
2002-04-16 13:14 ` law
2002-04-16 15:25 ` John David Anglin
2002-04-04 12:02 John David Anglin
-- strict thread matches above, loose matches on Subject: below --
2002-04-04 2:03 H.Merijn Brand
2002-04-04 8:22 ` law
[not found] ` <200204041958.g34JwTbA011272@hiauly1.hia.nrc.ca>
2002-04-05 4:51 ` H.Merijn Brand
2002-04-05 5:01 ` H.Merijn Brand
2002-04-05 9:19 ` John David Anglin
2002-04-07 7:26 ` H.Merijn Brand
2002-04-07 12:17 ` John David Anglin
2002-04-10 3:39 ` H.Merijn Brand
2002-04-10 11:21 ` John David Anglin
2002-04-10 11:56 ` H.Merijn Brand
2002-04-10 12:50 ` John David Anglin
2002-04-11 2:19 ` H.Merijn Brand
2002-04-11 8:59 ` John David Anglin
2002-04-11 9:15 ` H.Merijn Brand
2002-04-11 9:19 ` law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).