Re: gcc-64 on HP-UX 11.00

[H.Merijn Brand]

On Fri 05 Apr 2002 18:06, "John David Anglin" <address@hidden> 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: address@hidden
http://archives.develooper.com/address@hidden/   address@hidden
send smoke reports to: address@hidden, QA: http://qa.perl.org