This is the mail archive of the 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: C++ demangler horrors

On Tue, Jul 01, 2003 at 11:54:01AM -0300, Alexandre Oliva wrote:
> On Jul  1, 2003, "H. J. Lu" <> wrote:
> > I don't get it. Are you saying you can link with libiberty before
> > libiberty is done?
> No.  I'm just concerned about dependencies that might go missing.
> Modifying a file in a different directory is very bad practice in my
> book.
> > Can you tell me how a parallel build will fail with my proposal?
> At first, it seemed to me that it obviously didn't, but that still
> didn't make it right.
> Now consider a Cygwin build.  The Cygwin library must not depend on
> the demangle target, otherwise we're back to the original problem.
> But both the Cygwin library and the demangler depend on libiberty.
> Now consider that the Cygwin library may be linked with libiberty
> while the demangler modifies libiberty.  Oops.

The original problem is demangler depends on libstdc++ and on Cygwin
libstdc++ may depend on libiberty. I still don't see why Cygwin library
can't depend on both libstdc++ and demangler, which is libiberty

> Also, consider the case that the cygwin library might, for whatever
> reason, want to use the demangler from libiberty.  What now?  Should
> it really get the wrong demangler, or fail to link?

I don't see there is a problem. You can think it this way. Without
libstdc++, demangler and libiberty is a combined target. With libstdc++,
libstdc++, demangler and libiberty is a combined target. Can you tell
me where the problem is?


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