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