repost: libg++ won't build on alphaev56-dec-osf4.0d

Jeffrey A Law law@cygnus.com
Fri Dec 18 18:06:00 GMT 1998


  In message < orr9tyrp39.fsf@araguaia.dcc.unicamp.br >you write:
  > On Dec 18, 1998, Jeffrey A Law <law@upchuck.cygnus.com> wrote:
  > 
  > >   In message < orbtl2thcc.fsf@araguaia.dcc.unicamp.br >you write:
  > >> Using the same reasoning, I added -nostdlib to SHDEPS, so as to avoid
  > >> libgcc.a too, and it worked.
  > > That is wrong.  Consider if a shared library needs to use some code from
  > > libgcc.a
  > 
  > Then the program that links with the shared library should get a copy
  > of the code, since it's being linked with the library too.
Not good enough.

Consider if you have a shared library that is not bound into the program.  ie
you load it via shl_load/dl_open.  Call it shlib1.

For argument's sake, let's pretend shlib1 references __mulsi3.  Let's also
pretend that neither the main program nor any of the libraries which appear
on the link line reference __mulsi3.

Since nothing in the linked executable referenced __mulsi3, __mulsi3 will not
be a part of the main program's image.

Now we call shl_load/dl_open to suck in shlib1 to the running executable.  We
lose because nothing defines __mulsi3 for shlib1 to use.

We must link libgcc into shared libraries.  Note the same applies if you have
libstdc++.a -- it needs to be linked into shared libraries for the same reason.

jeff



More information about the Gcc-bugs mailing list