This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ demangler horrors
On Jul 1, 2003, Daniel Jacobowitz <drow@mvista.com> wrote:
> You're right. From my TODO:
> - all-target-winsup should depend on maybe-all-target-libstdc++-v3 ?
> I'm pretty sure about that, since highly parallel cygwin builds give an
> error now when winsup tries to link to libstdc++. Someone should fix
> it :)
Please propose the obvious patch to whatever the Cygwin development
mailing list is and if it's approved there, check it in here too ;-)
> Yes. Libiberty goes through contortions to make this work, I'd rather
> avoid extending those.
So does libstdc++-v3, for C++, and so does H.J.'s demangler
configure. Eek. This is getting worse :-)
/me wonders if we could:
1) when libiberty is configured for the build or host machine, just
check whether a C++ compiler is there, and use the result to decide
which demangler to build, and that's it.
2) when libiberty is configured for the target, do *not* test for a
C++ compiler. Instead, get configure-target-libiberty to depend on
configure-target-libstdc++-v3 (does this introduce any cycles?),
and just assume the C++ compiler is good enough to build the
C++ demangler into libiberty. We still need some logic for the
case of a C-only build, but I think this approach might work.
We'd only need some additional logic in libiberty to choose which
demangler to use, but we'd be able to use a single directory, and
build everything in a single pass, the way it should be.
Can anyone see any flaws in this suggestion?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer