This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A clue for the libstdc++ problem.
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.