Re: Compiling GCC with g++: a report

[Zack Weinberg <zack at codesourcery dot com>]

On Tue, 2005-05-24 at 09:41 -0400, Daniel Jacobowitz wrote:
> We've fixed a lot of these problems already; I will be brave and say
> that we have fixed most of them.

I'm glad you're optimistic about it.  It's good to have someone
balancing out pessimistic people like me. :)

> > This scenario, at least theoretically, becomes a non-issue if we make
> > top-level bootstrap the only option before we start using C++ features
> > in GCC, but that hasn't happened yet.
> 
> As Paolo wrote, it will soon.  This isn't the only thing it'll fix. 
> For instance it would let us use bool in those interfaces again,
> without breaking Darwin.

Actually it won't.  We could only use a real 'bool' if we switched to
C++.   Short of that, we can't count on bool being a real bool, so we
have to #define it to unsigned char everywhere so that no one
accidentally writes code that relies on bool having Boolean semantics.

You might think we could get away with it in stage 2, but that's
actually a recipe for comparison failures.

(I'm pleasantly surprised to report that HP's C++ compiler *doesn't*
have the bool/_Bool bugs that their C compiler does.)

> > Scenario two: Suppose that we have not found every last place where
> > LD_LIBRARY_PATH, or equivalent, needs to be set during bootstrap to
> > ensure that the dynamic linker binds the stage 2 compiler to the
> > shared libstdc++ that it's expecting.
> 
> With top level bootstrap this is trivial to get right.  The top level
> should set the library path appropriately for the stage.

Um, there have been plenty of cases in the past where the top level set
something correctly and the subdirectory makefiles overrode it with an
incorrect setting.

> You do realize that libgcc is "compatible" in the same way as glibc,
> right?  If you do this and don't copy the hypothetical gcc 4.3
> libgcc_s.so.1 into your system library directory, C++ stands a decent
> chance of not working.  Not a new problem.

No, not a new problem.  In a lot of ways, C++ use in GCC would inflict
on us the same problems we've been inflicting on our users since before
3.0.  ;-/

> I don't know why you think that the DT_RPATH would cause the build to
> fail.  A DT_RPATH pointing at a non-existant directory is harmless and
> LD_LIBRARY_PATH will still be used.  It's only if you had an old copy
> in $prefix that DT_RPATH would bite you.  And there are plenty of other
> ways around this - for instance, a shell script named xgcc in the build
> tree which LD_PRELOADs the correct copy using a full path.

I had misremembered what DT_RPATH did if the directory didn't exist; my
bad.

In private mail someone suggested $ORIGIN to me as a possible solution.
I really don't mean to be giving the impression that these are
intractable problems; I just don't want them considered non-problems.

> > I'd want to see at least two major releases with no libstdc++ soname
> > bump and no problems reported, before I had confidence we'd gotten
> > it right.
> 
> You mean, like GCC 3.4 and GCC 4.0?

If GCC 4.1 comes out without anyone having reported 3.4/4.0
incompatibilities, and continues to provide libstdc++.so.6, then yes,
that would be like what I mean.  However, the active development on the
libstdc++.so.7 branch means that we haven't even started the clock
running on this criterion yet.

zw