A patch for hppa1.1-hp-hpux10.20 w/ --enable-shared

A patch for hppa1.1-hp-hpux10.20 w/ --enable-shared

[Teemu Torma]

I seems that libgcc should not be linked into shared libraries
on hpux10.20, or almost all eh-tests will fail.  I guess the same is
true for the other hpux versions.  With this patch, there are no
unexpected failures in check-g++.

XPASS: g++.jason/destruct3.C - (test for bogus messages, line 38)
XPASS: g++.mike/dyncast1.C  Execution test
XPASS: g++.mike/dyncast2.C  Execution test
XPASS: g++.mike/eh33.C (test for excess errors)
XPASS: g++.mike/eh33.C  Execution test
XPASS: g++.mike/eh50.C (test for excess errors)
XPASS: g++.mike/eh50.C  Execution testg

                === g++ Summary ===

# of expected passes            3397
# of unexpected successes       7
# of expected failures          80
# of untested testcases         6

Teemu

1997-12-03  Teemu Torma  <tot@trema.com>

	* config/pa/pa-hpux.h (LIBGCC_SPEC): If -shared, do not link
	against libgcc.

Index: config/pa/pa-hpux.h
===================================================================
RCS file: /trema/cvs/gnu/egcs/gcc/config/pa/pa-hpux.h,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -c -r1.1.1.1 -r1.2
/usr/gnu/bin/diff: conflicting specifications of output style
*** pa-hpux.h	1997/09/26 09:58:01	1.1.1.1
--- pa-hpux.h	1997/12/03 11:06:57	1.2
***************
*** 32,37 ****
--- 32,41 ----
  #undef LIB_SPEC
  #define LIB_SPEC "%{!shared:%{!p:%{!pg:-lc}}%{p: -L/lib/libp/ -lc}%{pg: -L/lib/libp/ -lc}}"
  
+ #undef  LIBGCC_SPEC
+ #define LIBGCC_SPEC \
+   "%{!shared:-lgcc}"
+ 
  #undef CPP_PREDEFINES
  #define CPP_PREDEFINES "-Dhppa -Dhp9000s800 -D__hp9000s800 -Dhp9k8 -DPWB -Dhpux -Dunix -Asystem(unix) -Asystem(hpux) -Acpu(hppa) -Amachine(hppa)"
  

Re: A patch for hppa1.1-hp-hpux10.20 w/ --enable-shared

[Neal Becker]

Thanks!

Maybe if -shared we need to link with shared libgcc.sl?

Re: A patch for hppa1.1-hp-hpux10.20 w/ --enable-shared

[Neal Becker]

Actually, gcc-2.7.2.2 has this in the specs:

*libgcc:
%{!shared:-lgcc}

which I guess is the same thing change you're recommending to egcs.
Well it's been working fine for gcc-2.7.2.2, so I guess this is the
Right Thing To Do.

A patch for hppa1.1-hp-hpux10.20 w/ --enable-shared

[Teemu Torma]

    From:  Neal Becker <neal@ctd.comsat.com>
    Date:  03 Dec 1997 11:23:30 -0500

    Actually, gcc-2.7.2.2 has this in the specs:
    
    *libgcc:
    %{!shared:-lgcc}
    
    which I guess is the same thing change you're recommending to egcs.
    Well it's been working fine for gcc-2.7.2.2, so I guess this is the
    Right Thing To Do.
    
Yes, that was the default in 2.7.2, and seems to have been changed
at Dec 4 1995 according to ChangeLog.10.

Teemu

Re: A patch for hppa1.1-hp-hpux10.20 w/ --enable-shared

[Jeffrey A Law]

  In message < u97m9mm9oz.fsf@neal.ctd.comsat.com >you write:
  > Which means you have to build a pic version of libgcc, right?  On
  > hpux9, at least, you can't link a shared lib against non-pic code.
Not exactly.

You just need to have a PIC libgcc.a.

Jeff

Re: A patch for hppa1.1-hp-hpux10.20 w/ --enable-shared

[Jason Merrill]

>>>>> Neal Becker <neal@ctd.comsat.com> writes:

> Actually, gcc-2.7.2.2 has this in the specs:
> *libgcc:
> %{!shared:-lgcc}

> which I guess is the same thing change you're recommending to egcs.
> Well it's been working fine for gcc-2.7.2.2, so I guess this is the
> Right Thing To Do.

Nope.  We need to include libgcc in shared objects so they can be
dynamically loaded.

Jason

Re: A patch for hppa1.1-hp-hpux10.20 w/ --enable-shared

[Neal Becker]

>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

    Jeffrey>   In message < 199712031633.RAA04897@baht.labs.trema.com >you write:
    >> From:  Neal Becker <neal@ctd.comsat.com>
    >> Date:  03 Dec 1997 11:23:30 -0500
    >> 
    >> Actually, gcc-2.7.2.2 has this in the specs:
    >> 
    >> *libgcc:
    >> %{!shared:-lgcc}
    >> 
    >> which I guess is the same thing change you're recommending to egcs.
    >> Well it's been working fine for gcc-2.7.2.2, so I guess this is the
    >> Right Thing To Do.
    >> 
    >> Yes, that was the default in 2.7.2, and seems to have been changed
    >> at Dec 4 1995 according to ChangeLog.10.
    Jeffrey> You have to link with libgcc when building a shared library so that hte
    Jeffrey> shared library has copies of any libgcc2 functions it may need.

Which means you have to build a pic version of libgcc, right?  On
hpux9, at least, you can't link a shared lib against non-pic code.

Re: A patch for hppa1.1-hp-hpux10.20 w/ --enable-shared

[Jeffrey A Law]

  In message < 199712031633.RAA04897@baht.labs.trema.com >you write:
  >     From:  Neal Becker <neal@ctd.comsat.com>
  >     Date:  03 Dec 1997 11:23:30 -0500
  > 
  >     Actually, gcc-2.7.2.2 has this in the specs:
  >     
  >     *libgcc:
  >     %{!shared:-lgcc}
  >     
  >     which I guess is the same thing change you're recommending to egcs.
  >     Well it's been working fine for gcc-2.7.2.2, so I guess this is the
  >     Right Thing To Do.
  >     
  > Yes, that was the default in 2.7.2, and seems to have been changed
  > at Dec 4 1995 according to ChangeLog.10.
You have to link with libgcc when building a shared library so that hte
shared library has copies of any libgcc2 functions it may need.

Consider what happens if you build a shared library with gcc which needs
__muldi3 (64bit multiply from libgcc2).

If you don't link in libgcc, then the library has an undefined reference to
__muldi3.

Then consider what happens if a user tries to compile a program with "cc"
which links against the dynamic library with the undefined reference to
__muldi3.  The won't be any definition of __muldi3 available, and the program
will likely fail.

It's also possible to construct scenarios which involve only gcc compiled
code -- for example, consider the same library with an undefined reference
to __muldi3.

Then assume that the library is loaded at runtime via shl_load/dl_open call;
if the main program didn't reference __muldi3, then no definition of
__muldi3 is available and the program will likely fail.

The basic conclusion is the compilre must include any intrinsics in the 
shared library which are used by the shared library.  HP found this out the
hard way with their millicode routines, we shouldn't make the same mistake.

Jeff

A patch for hppa1.1-hp-hpux10.20 w/ --enable-shared

[Teemu Torma]

    From:  Jeffrey A Law <law@cygnus.com>
    Date:  Wed, 03 Dec 1997 11:29:17 -0800

    You have to link with libgcc when building a shared library so that hte
    shared library has copies of any libgcc2 functions it may need.

True.  On the other hand, C++ exception handling should work even if
linking against shared libraries.  

Of course the problem why it does not work should be fixed.  Otherwise 
someone will always be complaining.

Teemu