Problems building shared libraries under Irix6

Problems building shared libraries under Irix6

[Lee Iverson]

All of the discussion wrt. __register_frame under Linux (mostly on
gcc2 with spillover here) begs an important question: why is libgcc.a
linked in when building shared libraries?  Under Irix 6.x, this
inclusion on the link line seems to break shared libraries
completely.  They can no longer be linked against since
__register_frame was included.

If libgcc was a properly versioned shared library, however, things
might actually work.  For now, I'm experimenting with adding the
following lines to specs (note the conditionalization of %G on shared):

*link_command:
%{!fsyntax-only: %{!c:%{!M:%{!MM:%{!E:%{!S:ld %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}} %{static:} %{L*} %D %o %{!nostdlib:%{!nodefaultlibs: %{!shared: %G} %L %{!shared: %G}}} %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}}

At least now I don't get error messages at shared library link time.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: Problems building shared libraries under Irix6

[Jeffrey A Law]

  In message < 199712161724.JAA25082@Canada.AI.SRI.COM >you write:
  > 
  > All of the discussion wrt. __register_frame under Linux (mostly on
  > gcc2 with spillover here) begs an important question: why is libgcc.a
  > linked in when building shared libraries?  Under Irix 6.x, this
  > inclusion on the link line seems to break shared libraries
  > completely.  They can no longer be linked against since
  > __register_frame was included.
The shared library needs to be self-contained as far as functions for
internal use are concerned.

Consider __muldi3 for 64bit multiplies.

If you build a dynamic library which uses 64bit multiply, but do not link
in libgcc to the library, then the library will have a reference, but no
definition of __muldi3.

If you later load that library into a program via shl_load/dl_open and the
program does not have __muldi3 defined (because the main program never used
64bit multiplies), then you lose.

The __register_frame stuff is needed to make sure that unwinding
information for the shared library is registered so that you can throw
through a shared library.

Jim has a patch to move __register_frame and friends elsewhere so that
they don't cause multiple symbol definitions.  Assuming he thinks the patch
is correct, he should apply it so this problem goes away.

jeff

Re: Problems building shared libraries under Irix6

[Richard Henderson]

On Tue, Dec 16, 1997 at 05:19:34PM -0700, Jeffrey A Law wrote:
> Jim has a patch to move __register_frame and friends elsewhere so that
> they don't cause multiple symbol definitions.  Assuming he thinks the patch
> is correct, he should apply it so this problem goes away.

It might be worth considering making libgcc a shared library on at
least ELF platforms.  It would eliminate some of these problems,
though it would mean we'd have to be more careful with binary
compatibility and installation.

Just a thought...


r~

Re: Problems building shared libraries under Irix6

[Jeffrey A Law]

  In message < 19971216233439.16166@dot.cygnus.com >you write:
  > On Tue, Dec 16, 1997 at 05:19:34PM -0700, Jeffrey A Law wrote:
  > > Jim has a patch to move __register_frame and friends elsewhere so that
  > > they don't cause multiple symbol definitions.  Assuming he thinks the pat
  > ch
  > > is correct, he should apply it so this problem goes away.
  > 
  > It might be worth considering making libgcc a shared library on at
  > least ELF platforms.  It would eliminate some of these problems,
  > though it would mean we'd have to be more careful with binary
  > compatibility and installation.
  > 
  > Just a thought...
Hmmm, I thought we experimented with this a few years ago and decided
it was a bad idea (due to the shlib path problems I suspect).

Compiling libgcc stuff with -fPIC, but not making a shared library
got us most of the benefits without the major headaches.

jeff

Re: Problems building shared libraries under Irix6

[H.J. Lu]

> Hmmm, I thought we experimented with this a few years ago and decided
> it was a bad idea (due to the shlib path problems I suspect).

You may have to keep that libgcc.so for a long time even after
you have deleted the old compiler. Also it is one more share
library to load.

> 
> Compiling libgcc stuff with -fPIC, but not making a shared library
> got us most of the benefits without the major headaches.
> 

Yes.

-- 
H.J. Lu (hjl@gnu.org)