This is the mail archive of the
libstdc++@sources.redhat.com
mailing list for the libstdc++ project.
Re: Latest snapshot won't build with --enable-libstdcxx-v3
- To: Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>
- Subject: Re: Latest snapshot won't build with --enable-libstdcxx-v3
- From: Phil Edwards <pedwards at disaster dot jaj dot com>
- Date: Wed, 20 Sep 2000 12:51:46 -0400
- Cc: Joe Buck <jbuck at racerx dot synopsys dot com>, Benjamin Kosnik <bkoz at redhat dot com>, Benjamin Scherrey <scherrey at switchco dot com>, gcc at gcc dot gnu dot org, libstdc++ at sources dot redhat dot com
- References: <jbuck@racerx.synopsys.com> <200009201541.e8KFfr711897@mururoa.inria.fr>
On Wed, Sep 20, 2000 at 05:41:53PM +0200, Theodore Papadopoulo wrote:
> I was wondering what was the rationale behind redirecting the
> compiler messages to /dev/null which is exactly the opposite of the
> philosophy exposed above, ie expose the developers to the messages
> as much as possible!!!
My understanding is that libtool does this. Watch carefully as those
files are compiled; each source file is being compiled twice; one PIC and
one non-PIC. The first goes into the .so, the second goes into the .a.
Output and errors from the first are seen. Since the second compilation is
(presumably) producing the same warnings/errors as the first, its output
is sunk to keep duplicate noise out of the results.
And as you've seen, when the presence of PIC causes different results,
though, Bad Things happen...
Again, just my own conclusions. I could easily be wrong.
Phil
--
pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools. Fools are protected by more capable fools.