This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: Please review the new C++ demangler patch


On Thu, Jun 26, 2003 at 12:44:02AM -0300, Alexandre Oliva wrote:
> On Jun 25, 2003, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > I don't want to force the change of the build order between libiberty
> > and libstdc++ in this patch. It may cause other problems.
> 
> I think it will cause problems for Cygwin.
> 
> I strongly dislike the idea of replacing object files in a library
> created in a different directory.  It will make parallel builds even
> messier than they are.  Let's please try to find another way to do it.
> 

It looks like the issues people have with my demengler patch are:

1. There shouldn't be a separate demengler directory.
2. Use "ar" to manipulate libiberty.a is fragile at best.
3. There should be a clearer separation at source code level between
demangler for libiberty and demangler for libstdc++.

I will try to address those issues here. A separate demengler directory
is desirable for maintenance. We may not want to make the demengler
maintainer to get approval for any changes from a libiberty maintainer.
It doesn't mean we can't build it in libiberty. My patch does that
for libstdc++. The main issue is the build order for target. I don't
want the build order issue, which may affect many platforms, blocks the
demengler patch. That is why I use "ar". We can build demengler in
libiberty after the build order issue is resolved. My current patch
makes sure every package which needs demengler depends on libiberty
as well as demengler. I have no problems with parallel build on several
fast SMP machines.

The new demengler is written in C++ and uses libstdc++. I am not in the
business writing a new libstdc++ just for demengler nor I believe any
gcc developers should. The only reason some replacement classes are
used for demengler in libiberty is we want the resulting demangle.o
self-contained so that we can use it as a C function and doesn't
require libstdc++.{so|a}. I don't see why any gcc developers want to
change it.


H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]