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

[Jeffrey A Law <law@cygnus.com>]

  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