This is the mail archive of the
mailing list for the GCC project.
Re: hpux specific installation notes for GCC
- To: law at cygnus dot com
- Subject: Re: hpux specific installation notes for GCC
- From: Markus Werle <markus at lufmech dot rwth-aachen dot de>
- Date: Wed, 27 Sep 2000 18:06:47 +0200
- CC: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>, gcc-patches at gcc dot gnu dot org
- References: <14238.970065915@upchuck>
Jeffrey A Law wrote:
Thank You. Now I get some statements I waited for a long time.
There *are* people who have g++ on hpux-11.0 running perfectly?
> NO. I disagree strongly with most of the statements.
You are right.
I believe my statements are a brute force attack
trying to get it run on that system.
> First, GCC should be bootstrappable with GCC or the HP compilers (bundled
> or unbundled).
It was not. Especially using gcc-2.95.2 as a starting point for newer
releases makes a bootstrap impossible -> ICE.
I tried a lot of patches related to hp cc and ld, but I had not too much success.
Last week was the first time it bootstrapped with a brand new binutils snapshot
(alloca in disabled by hand) without ICEs et al..
See some of my pain with hpux-10.20 and 11.0 in
> Second, I do *not* recommend using the binaries at hpux.cs.utah.edu.
Me, too. But when the sources refuse to build You can at least rely on those.
And they seem to do what they should .... I got fed up with cvs and gmake etc.
when I had to rely on hp-cc.
I wanted to propose this unix-shell-pseudo-code:
# install precompiled; build gcc; test gcc && \
build --with-new-gcc all-gnu-software && \
uninstall precompiled; install all-gnu-software && \
be happy; live long;
> Third, you should be able to use hpux11 (32 bit mode) without using a
> binutils snapshot.
I tried at least 8 different binutils from within this year.
Guess how I laugh reading Your comment.
Sorry, I insist on : "take the latest snapshot" until someone tells me
which of the older versions does the job.
Oh! Maybe I accidentally configured for the 64bit mode???
how can I check this?
> Fourth, you do not need bison, if you ever need bison to build a release,
> then there's a bug somewhere.
Yes, I know, but there *was* a bug last week.
Installing a precompiled bison prevented me from jumping out of the window. :-)
> There shouldn't be any problems with alloca. I've been developing on this
> platform for years and it should just work.
There shouldn't, but there were ...
and the whole thread and recent discussion there (or the comments in the
binutils source code)
on Your machine. If You have no alloca problem with that one, we will have to
push the alarm.
Tomorrow's binutils will have a patch which - if I understand well -
switches back from hp's alloca to the binutils's alloca in order to
fix that problem.
> I do not encourage an explicit path to the assembler. Never have, never
> will. There are better ways to solve that problem.
I got rid of a lot of nasty bootstrap errors by using this feature.
And I am freed of changing my PATH every time I change binutils.
Which better ways do You propose?
Is it dangerous to use this option?
Let me give a summary of current state:
With disabled alloca in today's binutils (but still there in gcc) I am able to
today's gcc. I am able to compile petsc-2.0.28 with g++ on hpux-11.0, but the
(not everywhere) errors due to linkage problems (unresolved symbols) concerning
the fresh petsc-libs. nm seems to find those symbols
Same problems with my own code. petsc-stuff is not found.
If I bootstrap a "configure --without-gas" the number of
missing symbols is slightly bigger (adds explicitly instantiated templates) .
I tried to write a little testsuite, but the error is not reproducable for small
I tested my own package and petsc on Linux so I am sure, nothing goes wrong with
or the way I build/install petsc.
One of my guesses:
Something may go wrong with very long symbol names > 1000 chars
(I have them because of extreme use of expression templates ...)
Any idea how to cut their length automagically?
And: keyword "weak symbols" is modern right now for gcc-hpux discussion.
Search it and You find it much too often.
P.S.: Thanks for that great C++ compiler, anyway.
The linux box does not make trouble. And aCC is not an alternative ...