A clue for the libstdc++ problem.

[H . J . Lu]

On Sun, Apr 01, 2001 at 07:44:56PM -0300, Alexandre Oliva wrote:
> On Apr  1, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> 
> > Please keep in mind that building the shared libstdc++ is a special
> > case, just like building libc.so.
> 
> It's not just like building libc.so.  The main difference is that we
> don't have a compiler driver that won't link in libc by default, but
> gcc will not link libstdc++ in, whereas g++ will.  Arranging for us to

You missed the point. We don't use the normal way for building C shared
libraries like

# gcc -shared -o libfoo.so foo.o bar.o ....

to build libc.so not should libstdc++.so. Can you image using today's
libtool in glibc?

> use gcc while building libstdc++ is enough.  We don't have to pollute
> libtool scripts with this special case.  Especially with assumptions

But you put all kinds of kludges in gcc. If libstdc++ uses libtool,
it should be able to tell libtool to do something special for some
special libraries. It can be local to gcc.

> about directory names, which strikes me as a very bad idea.

I said in my message:

---
Here is a kludge. It is not a correct solution for the libstdc++
problem. But I hope you can get some clues.
---


H.J.