RE: link errors with simple c++ prog on hpux10/11/a couple others

["Neulinger, Nathan R." <nneul at umr dot edu>]

> -----Original Message-----
> From: Martin v. Loewis [mailto:martin@loewis.home.cs.tu-berlin.de]
> Sent: Wednesday, July 05, 2000 3:52 PM
> To: nneul@umr.edu
> Cc: bug-gcc@gnu.org
> Subject: Re: link errors with simple c++ prog on hpux10/11/a couple
> others
> 
> 
> > gcc bootstraps just fine. Looks like everything works, however, when
> > linking a g++ program, it gets undefined symbols that 
> should probably be
> > in libstdc++. This does not occur on a linux build. gcc 
> works just fine
> > on all the platforms.
> 
> These symbols should come from libgcc.a. Couly you please verify that
> they are there, and analyse why they aren't used?

opvdel.o:
00000000 t $CODE$
000001fc t L$0005
000001c8 t L$0012
0000009c t L$0017
000000bc t L$0018
00000188 t L$0019
00000000 t L$text0000
00000000 t L$text_end0000
         U __builtin_delete
00000000 t __builtin_vec_delete
         U __check_null_eh_spec
         U __cp_pop_exception
         U __get_eh_context
         U __sjthrow
         U __start_cp_handler
         U __terminate

They seem to all be there, defined locally (t). 

I built with ld -v, and noticed this:
Searching library
/umr/testbin/../lib/gcc-lib/hppa2.0-hp-hpux10.20/2.96/libgcc.a:
Searching library /usr/lib/libdld.1:
Searching library /usr/lib/libc.sl:
Searching library
/umr/testbin/../lib/gcc-lib/hppa2.0-hp-hpux10.20/2.96/libgcc.a:
WARNING:  LIBRARY
/umr/testbin/../lib/gcc-lib/hppa2.0-hp-hpux10.20/2.96/libgcc.a HAS OVERFLOW
SYMBOLS; USE CLEANRL
Searching library ./libgcc.a:
WARNING:  LIBRARY ./libgcc.a HAS OVERFLOW SYMBOLS; USE CLEANRL
Searching library /usr/lib/milli.a:
  Selecting div_const.o to resolve $$divI_10
    referenced from /usr/ccs/lib/crt0.o
  Selecting dyncallU.o to resolve $$dyncall
    referenced from /usr/ccs/lib/crt0.o

I'm not sure what the CLEANRL is. It's hp's linker, since binutils doesn't
have ld for hpux.

> > Also, is libstdc++-v3 supposed to be supported on other than just
> > glibc based systems?
> 
> Yes, but it would need to be ported to other systems. It is currently
> ported to a number of Solaris versions. I'm sure a port to HP/UX would
> be appreciated.

That makes sense, but it doesn't look like it's set up to be ported - with
the way those files/defines are hardcoded into config files included by all
the source files.

-- Nathan