Installing snapshot on HP-UX

[Marco Franzen <marcof at thyron dot com>]

Hi,

I have had trouble installing several adjacent snapshots on HP-UX. 
20001002 did not bootstrap at all.
(I tried only default bootstrap cflags and patched it up to later snapshots then).

1009 and 1016 bootstrapped fine, but the installed version cannot link
against its STL for some reason. A simple `int main () { return 0; }'
works, but  already "hello world" does not. (I haven't tried 1023; on my
slow box, a full bootstrap takes more than a day.)

The symptom is undefined symbols (for entirely newly compiled code; no old
objects being linked against): [This is from 1009. I tried 1016 first and 
did a make install from the 1009 compilation directory afterwards. The
type of failure was the same.]

bash-2.03$ cat > world.cpp
#include <iostream>
int main() { cout << "Hello world\n"; return 0; }
bash-2.03$ ~/gnu/bin/g++ -v world.cpp -o world
Reading specs from /home/marcof/gnu/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.97/specs
Configured with:  --prefix=/home/marcof/gnu --with-gnu-as
gcc version 2.97 20001009 (experimental)
 /home/marcof/gnu/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.97/cpp0 -lang-c++ -D__GNUG__=2 -v -D__GNUC__=2 -D__GNUC_MINOR__=97 -D__GNUC_PATCHLEVEL__=0 -Dhppa -Dhp9000s800 -D__hp9000s800 -Dhp9k8 -DPWB -Dhpux -Dunix -D__hppa__ -D__hp9000s800__ -D__hp9000s800 -D__hp9k8__ -D__PWB__ -D__hpux__ -D__unix__ -D__hppa -D__hp9000s800 -D__hp9k8 -D__PWB -D__hpux -D__unix -Asystem(unix) -Asystem(hpux) -Acpu(hppa) -Amachine(hppa) -D__STDC_HOSTED__=1 -D_PA_RISC1_1 -D__hp9000s700 -D_HPUX_SOURCE -D_HIUX_SOURCE -D__STDC_EXT__ world.cpp /var/tmp/ccmNmTwB.ii
GNU CPP version 2.97 20001009 (experimental) (cpplib) (hppa)
#include "..." search starts here:
#include <...> search starts here:
 /home/marcof/gnu/include/g++-3
 /usr/local/include
 /home/marcof/gnu/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.97/include
 /home/marcof/gnu/hppa1.1-hp-hpux10.20/include
 /usr/include
End of search list.
 /home/marcof/gnu/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.97/cc1plus -lang-c++ /var/tmp/ccmNmTwB.ii -quiet -dumpbase world.cpp -version -o /var/tmp/cc4CtodE.s
GNU C++ version 2.97 20001009 (experimental) (hppa1.1-hp-hpux10.20) compiled by GNU C version 2.97 20001009 (experimental).
 /home/marcof/gnu/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.97/../../../../hppa1.1-hp-hpux10.20/bin/as -o /var/tmp/ccfWeoVh.o /var/tmp/cc4CtodE.s
 /home/marcof/gnu/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.97/collect2 -L/lib/pa1.1 -L/usr/lib/pa1.1 -z -u main -o world /usr/ccs/lib/crt0.o -L/home/marcof/gnu/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.97 -L/usr/ccs/bin -L/usr/ccs/lib -L/opt/langtools/lib -L/home/marcof/gnu/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.97/../../.. /var/tmp/ccfWeoVh.o -lstdc++ -lm -lgcc -lc -lgcc
/usr/ccs/bin/ld: Unsatisfied symbols:
   bad_typeid virtual table(data)
   ios virtual table(data)
   type_info type_info function(code)
   stdiobuf virtual table(data)
   type_info virtual table(data)
   bad_alloc::~bad_alloc(void)(code)
   bad_cast virtual table(data)
   bad_typeid::~bad_typeid(void)(code)
   bad_cast type_info function(code)
   filebuf virtual table(data)
   bad_alloc type_info function(code)
   ios type_info function(code)
   bad_alloc virtual table(data)
   exception type_info function(code)
   exception virtual table(data)
   bad_cast::~bad_cast(void)(code)
   bad_typeid type_info function(code)
   __user_type_info type_info function(code)
collect2: ld returned 1 exit status

For bootstrapping I used gcc 2.95.2 (release), which had been installed in
our local standard hierarchy with `--prefix=/usr/gnu' (and `--with-gas').
I configured and installed the snapshot under a fresh directory
/home/marcof/gnu with only a link to gas in it (under
hppa1.1-hp-hpux10.20/bin/as). (I did not want to jeopardise the working
release version installation but wanted to "install" it just somewhere to 
avoid having to specify -B when using it.) Yes, I did a full bootstrap. 

But I do not think my problem has anything to do with the old installation.
The linker invocation does not mention the old hierarchy.

After patching, I needed to use bison (1.28) and autoconf (2.13).
[See my bug report on that in
<http://gcc.gnu.org/ml/gcc-bugs/2000-10/msg00476.html>.]
Hope those are the right versions.
I compiled in a different directory (vpath) using GNU make (3.79.1).

Am I doing anything wrong here? I haven't seen any bug reports in the
archive for these snapshots.

BTW, the only reason why I need the snapshot on that box is that I am
suspecting a bug in the 2.95.2 release version. Maybe someone knows
anything about that. A larger application fails to run correctly apparently
because some objects have a "split personality". I have a template class
that represents some logically class-static container as
function-static local to a static member "wrapper" function that just
returns a reference to the container (for fine-control of its life time). 
Instantiations of that template class (with identical actual template 
arguments as confirmed by typeid) in different compilation units seem get 
different instantiations rather than a shared container. On another platform 
(i586-sco-sysv5uw7.1.0) it works as expected with a snapshot version 
(0814, platform not supported by 2.95.2).
Even on the HP-UX 2.95.2 it works correctly if I single-step it under gdb,
but not if I just run it under the debugger.

Any help or hint will be appreciated.

Cheers,

Marco
===========
[End of my message.  I am speaking only for myself.  Anything after the
closing bracket is not part of my message.  I did intend to send this 
to an open list.]
-----------------------------------------------------------------
This email is confidential and intended solely for the use of the
individual to whom it is addressed.
Any views or opinions presented are solely those of the author
and do not necessarily represent those of Thyron Limited.
If you are not the intended recipient then please be advised
that you have received this email in error and that any use,
dissemination, forwarding, printing or copying of this email
is strictly prohibited.
If you have received this email in error, please notify the
Thyron IT Administrator on +44 (0)1923 236 050 or
send an email to mail-admin@thyron.com.
Thank You